Distributed transactions
This presentation is the property of its rightful owner.
Sponsored Links
1 / 35

Distributed Transactions PowerPoint PPT Presentation


  • 83 Views
  • Uploaded on
  • Presentation posted in: General

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.

Download Presentation

Distributed Transactions

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


Distributed transactions

Distributed Transactions


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.


  • Login