2 – Phase Commit Protocol

Commit Protocol

[amazon_link asins=’5514267202′ template=’ProductAd’ store=’encrypt0f-21′ marketplace=’IN’ link_id=’76316f3b-7ae5-11e7-9e9e-57646544fd56′]

In transaction processing, databases & comp. n/w, the 2 Phase commit is a type of atomic commitment protocol ( ACP ). It is distributed algo. that co-ordinates all the process that participate in distributed atomic transactions. ( commit/rollback)

This protocol achieves its goal even in many cases of temporary system failure ( involves process, n/w node, comm. etc) and thus widely utilized.

Recovery

To accommodate recovery from failure, the protocols participates use logging ( logs ) of the protocol state. Logs records which are typically slow to generate but survive failures are used by protocol for recovery failure.

2 Phases of Protocol

1. The commit-request phase : ( Voting Phase )

 In which a co-ordinator process attempts to prepare all the transaction’s participating processes to take the necessary steps for either committing or aborting the transaction & to vote either
                               YES ==> Commit                                 NO ==> Abort
YES  :   if the transaction participates local portion execution has ended properly
NO   :   if the problem has been detected with the local portion

2. Commit Phase

Based on voting; the co-ordinator decides whether to commit or rollback & notifies the result to all cohorts. The cohorts then fallow with the needed actions ( commit/abort ) with their local transaction resources & their respective portion in transaction.

Basic Algorithm

Assumptions:
                               Master site  :  One node is designated as co-ordinator
                               Cohorts        :   Rest of the nodes
Protocol assumes that there is a stable-storage at each node with write-ahead log. ( No data loss/no crash in log of each node & two can comm. with each other )

1. Commit Request Phase ( Voting Phase )

The co-ordinator sends a query to commit message to all cohorts & waits until it receive a reply from all cohorts.
The cohorts executes the transaction upto the point, where they will be asked to commit ( Entry written to both undo & redo log buffer )
Each cohort replies with an agreement message ( Yes/No)
                               Yes ==> if the cohorts action succeeded
                               No ==> if cohorts actions fails ( impossible to commit )

2.Commit Phase ( Completion Phase )

 2.1)  Success

  •    The co-ordinator receives “ YES “ message from all cohorts
  •    Co-ordinator     =============>    Cohorts (all)
                                          Commit msg.
  •     Each cohorts complete the operation & releases all the locks & resources held during transaction.
  •     Each Cohorts    =================>  Co-ordinator
                                          Send Acknowledgment
  •     Co-ordinator completes the transaction when all acknowledgment have been received.

 

2.2)  Failure ( “NO” )

  •     If cohorts votes “NO” during the commit-request phase ( or the co-ordinator timeout expires )
  •     Co-ordinator     =============>    Cohorts (all)
                                             Rollback msg.
  •     Each cohorts undo the transaction using undo log buffer & releases all the locks & resources held    during transaction.
      
  •    Each Cohorts    =================>  Co-ordinator
                                        Send Acknowledgment
  •     Co-ordinator undoes the transaction when all acknowledgment have been received.

Disadvantage of 2PC

  •  It is a blocking protocol.
  • If Co-ordinator fails permanently, some cohorts never resolve their transactions.
          Eg.
        After a cohort has sent an agreement message to co-ordinator cohort is blocked until is commit/rollback msg. is received back by co-ordinator.