distributed transactions. structures of distributed transactions source: g. coulouris et al.,...
TRANSCRIPT
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 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
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.