Distributed Transactions

1. Distributed Transactions Yih-Kuen Tsay Dept. of Information Management National Taiwan University Distributed Transactions -- 1

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

3. Flat vs. Nested Transactions • 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). Distributed Transactions -- 3

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

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

6. Atomic Commitment inFlat 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. Distributed Transactions -- 6

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. Distributed Transactions -- 7

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

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

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

11. Atomic Commitment inNested 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. Distributed Transactions -- 11

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

13. Operations in Coordinator forNest Transactions Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Distributed Transactions -- 13

14. Two-Phase Commit inNested 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. Distributed Transactions -- 14

15. Two-Phase Commit inNest Transactions (cont.) Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Distributed Transactions -- 15

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. Distributed Transactions -- 16

17. The canCommit? Operation forTwo-Phase Commit in Nested Transactions Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition. Distributed Transactions -- 17

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

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. Distributed Transactions -- 19

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. Distributed Transactions -- 20

21. Optimistic Concurrency Control • If only one transaction may perform validation at the same time, commitment deadlocks might occur. Distributed Transactions -- 21

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. Distributed Transactions -- 22

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. Distributed Transactions -- 23

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

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. Distributed Transactions -- 25

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

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

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. Distributed Transactions -- 28

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 Distributed Transactions -- 29

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

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

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

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 Distributed Transactions -- 33

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

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 Distributed Transactions -- 35

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

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

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

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