1. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 1 Distributed Transactions Yih-Kuen Tsay Dept. of Information Management National Taiwan University

2. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 2 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Structures of Distributed Transactions

3. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 3 Both types of transaction invoke operations in more than one server. A flat transaction accesses servers’ objects sequentially. The subtransactions of a nested transaction can run in parallel (concurrently). Flat vs. Nested Transactions

4. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 4 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. * The four subtransactions can run in parallel. A Nested Banking Transaction

5. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 5 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. * A transaction identifier may include the server identifier and a serial number. A Distributed Banking Transaction

6. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 6 Atomic Commitment in Flat Transactions When a distributed flat transaction comes to an end, either all or none of its operations (in different servers) are carried out. If one part of a transaction for some reasons (e.g., server crash, failure of validation) has to abort, then the whole transaction must also be aborted.

7. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 7 The Two-Phase Commit Protocol A participant (server) is allowed to abort its part of a transaction (even after performing all operations). In the first phase, each server votes for the transaction to be committed or aborted. In the second phase, every server carries out the joint decision. The protocol tolerates server crashes or message losses.

8. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 8 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. * A participant is prepared to commit when it has recorded the changes and its status in permanent storage. The Two-Phase Commit Protocol (cont.)

9. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 9 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. The Two-Phase Commit Protocol (cont.)

10. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 10 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. The Two-Phase Commit Protocol (cont.)

11. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 11 Atomic Commitment in Nested Transactions When a subtransaction completes, it makes an independent decision either to commit provisionally or to abort. A parent transaction may commit even if one of its child transactions has aborted. If a parent transaction aborts, then its subtransactions will be forced to abort. Subtransactions will not carry out a real commitment unless the entire nested transaction descides to commit.

12. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 12 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. * A provisional commit is not backed up in permanent storage. Deciding Whether to Commit

13. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 13 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Operations in Coordinator for Nest Transactions

14. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 14 Two-Phase Commit in Nested Transactions When a subtransaction provisionally commits, it reports its status and the status of its descendants to its parent. When a subtransaction aborts, it just reports abort to its parent. Eventually, the top-level transaction receives a list of all subtransactions (except the descendants of an aborted transaction) in the tree, together with the status of each.

15. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 15 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Two-Phase Commit in Nest Transactions (cont.)

16. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 16 (Flat) Two-Phase Commit Protocol The top-level coordinator sends canCommit? to all sub-coordinators in the provisional commit list. When a server receives a canCommit?... –If it has provisionally committed substractions prepares those without aborted ancestors for commitment, aborts those with aborted ancestors, and sends a Yes vote to the coordinator. –Otherwise (it must have failed), sends a No vote.

17. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 17 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. The canCommit? Operation for Two-Phase Commit in Nested Transactions

18. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 18 Concurrency Control in Distributed Transactions Each server applies concurrency control to its own objects. Every pair of transactions are serializable in the same order at all servers.

19. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 19 Locking Each server maintains locks for its own objects. Locks cannot be released until the transaction has been committed or aborted at all servers. Distributed deadlocks might occur if different servers impose different orderings on transactions.

20. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 20 Timestamp Ordering A globally unique transaction timestamp is issued by the top-level coordinator. All servers must agree on how the timestamps are ordered. Conflicts are resolved as each operation is performed.

21. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 21 Optimistic Concurrency Control If only one transaction may perform validation at the same time, commitment deadlocks might occur. Transaction TTransaction U Read(A) at X Write(A) Read(B) at Y Write(B) Read(B) at Y Write(B) Read(A) at X Write(A)

22. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 22 Optimistic Concurrency Control (cont.) Parallel validation prevents commitment deadlocks. A parallel validation checks (among other things) conflicts between write operations of the transaction being validated against the write operations of other concurrent transactions.

23. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 23 Optimistic Concurrency Control (cont.) To ensure that transactions at different servers are globally serializable, the servers may –conduct a global validation (checking if there is a cyclic ordering) or –use the same globally unique transaction number for the same transaction.

24. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 24 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. An Interleaving of Three Transactions

25. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 25 Distributed Deadlocks A cycle in the global wait-for graph (but not in any single local one) represents a distributed deadlock. A deadlock that is detected but is not really a deadlock is called a phantom deadlock. Two-phase locking prevents phantom deadlocks; autonomous aborts may cause phantom deadlocks.

26. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 26 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Distributed Deadlocks and Wait-For Graphs

27. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 27 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Local and Global Wait-For Graphs

28. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 28 Edge Chasing Initiation: when a server notes that a transaction T starts waiting for another transaction U, which is waiting to access an object at another server, it sends a probe containing  T  U  to the server of the object at which transaction U is blocked.

29. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 29 Edge Chasing (cont.) Detection: receive probes and decide whether deadlock has occurred and whether to forward the probes. When a server receives a probe  T  U  and finds the transaction that U is waiting for, say V, is waiting for another object elsewhere, a probe  T  U  V  is forwarded. Resolution: select a transaction in the cycle to abort

30. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 30 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Probes for Detecting Deadlocks

31. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 31 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Independently Initiated Probes

32. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 32 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Probes Traveling Downhill

33. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 33 Transaction Recovery Requirements: durability and failure atomicity Specific goal: restore the server with the latest committed versions of its objects. Tasks of the recovery manager: –Save objects in permanent storage (a recovery file) –Restore objects after a crash –Reorganize the recovery file and reclaim storage –Optional: be resilient to media failures

34. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 34 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Types of Entry in a Recovery File

35. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 35 Two Approaches to the Use of Recovery Files Logging –Basic ideas: history of transactions, snapshots, … –Recovery of objects: forward or backward –Checkpointing Shadow versions –Basic ideas: map, shadow version, version store, … –Switching from the old map to the new map –Checkpointing

36. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 36 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Log for Banking Service

37. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 37 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Shadow Versions

38. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 38 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. A Log for the Two-Phase Commit Protocol

39. IM NTU Distributed Information Systems 2004 Distributed Transactions -- 39 Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Recovery of the Two-Phase Commit Protocol