Distributed Transactions

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

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

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

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.

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.

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

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

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

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

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.

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.

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

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.

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

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.

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.

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.

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.

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.

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

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 Deadlocks and Wait-For Graphs Source: G. Coulouris et al., Distributed Systems: Concepts and Design, Third Edition.

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

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.

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

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

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

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

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

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

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

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

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

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