Distributed Transactions

Structures of Distributed Transactions

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

A Nested Banking Transaction


A Distributed Banking Transaction


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


The Two-Phase Commit Protocol


The Two-Phase Commit Protocol (cont’d)


Operations for Coordinating Distributed Transactions


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


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


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


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


Local and Global Wait-For Graphs


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 TU 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 TU and finds the transaction that U is waiting for, say V, is waiting for another data item elsewhere, a probe TUV is forwarded.

• Resolution: select a transaction in the cycle to abort

Probes for Detecting Deadlocks


Independently Initiated Probes


Probes Traveling Downhill


Types of Entry in a Recovery File


Log for Banking Service


Shadow Versions


A Log for the Two-Phase Commit Protocol


Recovery of the Two-Phase Commit Protocol


Distributed Transactions

Documents

Transcript of Distributed Transactions