Distributed Transactions

1. Distributed Transactions

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

3. A Nested Banking Transaction Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

4. A Distributed Banking Transaction Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

5. Atomic Commitment • When a distributed (flat) transaction comes to an end, either all or none of its operations are carried out. • Due to atomicity, if one part of a transaction is aborted, then the whole transaction must also be aborted.

6. The Two-Phase Commit Protocol • The two-phase commit protocol is designed to allow any server to abort its part of a transaction. • 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.

7. Operations in the Two-Phase Commit Protocol Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

8. The Two-Phase Commit Protocol Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

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

10. Operations for Coordinating Distributed Transactions Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

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. • Subtransactions will not carry out a real commitment unless the entire nested transaction descides to commit.

12. Atomic Commitment in Nested Transactions (cont’d) • When a nested transaction provisionally commits, it reports its status and the status of its descendants to its parent. • When a nested transaction aborts, it just reports abort to its parent. • Eventually, the top-level transaction receives a list of all the subtransactions (except the descendants of an aborted transaction) in the tree, together with the status of each.

13. Deciding Whether to Commit Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

14. Two-Phase Commit in Nest Transactions When a server receives a CanCommit?... • If it has provisionally committed substractions, then it * 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), it sends a No vote.

15. Information for a Nested Transaction Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

16. Locking • Each server maintains locks for its own data items. • 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.

17. Locking (cont’d) • Parent transactions are not allowed to run concurrently with their child transactions. • To acquire a read lock, all holders of write lock on the data item must be ancestors. • To acquire a write lock, all holders of read and write locks on the data item must be ancestors. • When a nested transaction commits, its locks are inherited by its parent; when a nested transaction aborts, its locks are removed.

18. Timestamp Ordering • A globally unique transaction timestamp is issued by the coordinator. • Conflicts are resolved as each operation is performed. • If the resolution of a conflict requires a transaction to be aborted, the coordinator will be informed.

19. Optimistic Concurrency Control • If only one transaction may perform validation at the same time, commitment deadlocks might occur; parallel validation does not have the problem. • A parallel validation checks (among other things) conflicts between write operations of the transaction being validated against the write operations of other concurrent transactions.

20. Optimistic Concurrency Control (cont’d) • 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.

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

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

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

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

25. Edge Chasing • Initiation: when a server notes that a transaction T starts waiting for another transaction U, which is waiting to access a data item at another server, it sends a probe containing TU to the server of the data item at which transaction U is blocked.

26. Edge Chasing (cont’d) • 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 data item elsewhere, a probe TUV is forwarded. • Resolution: select a transaction in the cycle to abort

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

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

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

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

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

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

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

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

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