Flat transaction

• Client makes requests to more than one server.
• Flat client transaction completes each of its requests before going on to the next one. 
• Each transaction accesses servers’ objects sequentially. 
• When servers use locking, a transaction can only be waiting for one object at a time.

Nested transaction

• Top-level transaction can open subtransactions, and each subtransaction can open further subtransactions down to any depth of nesting. 
• Subtransactions at the same level can run concurrently. 
• In the following figure, the four requests (two deposits and two withdraws) can run in parallel and the overall effect can be achieved with better performance than a simple transaction in which the four operations are invoked sequentially.
  
  

  Figure 28: Distributed transactions
  
  

Figure 29: Nested banking transaction

Atomicity property requires that when a distributed transaction comes to an end, either all of its operations are carried out or none of them. 

• The client has requested operations at more than one server.
• A transaction comes to an end when the client requests that it be committed or aborted. 

One-phase atomic commit protocol

• The coordinator communicate the commit or abort request to all of the participants in the transaction and to keep on repeating the request until all of them have acknowledged that they have carried it out. 
• This is inadequate, because it does not allow a server to make a unilateral decision to abort a transaction when the client requests a commit.
• Server might want to abort due to concurrency control (resolve deadlock) or server has crashed and been replaced during the progress of a distributed transaction.

Two-phase commit protocol

• Allow any participant to abort its part of a transaction.
• Atomicity: if one part of a transaction is aborted, then the whole transaction must be aborted.
• First phase:
  • Each participant votes for the transaction to be committed or aborted.
  • Once a participant has voted to commit a transaction, it is not allowed to abort it.
  • So, before a participant votes to commit, it must ensure that it will eventually be able to carry out its part of the commit protocol. 
  • A participant is said to be in a prepared state for a transaction if it will eventually be able to commit it. 
  • Each participant saves in permanent storage all of the objects that it has altered in the transaction, together with its status – prepared.
• Second phase:
  • Every participant in the transaction carries out the joint decision. 
  • If any of the participant votes to abort, then the decision must be to abort the transaction. 
  • If all the participants vote to commit, then the decision is to commit the transaction.
    
    
    

    Figure 4: Operations for two-phase commit protocol
    
    Figure 5: The two-phase commit protocol