Distributed transactions
Download
1 / 35

Distributed Transactions - PowerPoint PPT Presentation


  • 110 Views
  • Uploaded on

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.

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Distributed Transactions' - zitkalasa-ramirez


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

Structures of distributed transactions
Structures of Distributed Transactions

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


A nested banking transaction
A Nested Banking Transaction

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


A distributed banking transaction
A Distributed Banking Transaction

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


Atomic commitment
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

  • 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
Operations in the Two-Phase Commit Protocol

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


The two phase commit protocol1
The Two-Phase Commit Protocol

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


The two phase commit protocol cont d
The Two-Phase Commit Protocol (cont’d)

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


Operations for coordinating distributed transactions
Operations for Coordinating Distributed Transactions

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


Atomic commitment in nested 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
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
Deciding Whether to Commit

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


Two phase commit in nest transactions
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
Information for a Nested Transaction

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


Locking
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
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
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
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
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
An Interleaving of Three Transactions

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


Distributed deadlocks
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
Distributed Deadlocks and Wait-For Graphs

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


Local and global wait for graphs
Local and Global Wait-For Graphs

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


Edge chasing
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
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
Probes for Detecting Deadlocks

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


Independently initiated probes
Independently Initiated Probes

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


Probes traveling downhill
Probes Traveling Downhill

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


Types of entry in a recovery file
Types of Entry in a Recovery File

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


Log for banking service
Log for Banking Service

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


Shadow versions
Shadow Versions

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


A log for the two phase commit protocol
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
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 protocol1
Recovery of the Two-Phase Commit Protocol

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


ad