DDBMS - Commit Protocols

DDBMS - Commit Protocols

In a local database system, the transaction manager just needs to communicate the decision to the recovery manager in order to commit a transaction. In a distributed system, however, the transaction manager can transmit the decision to commit to all the servers on the various sites where the transaction is being performed and implement the decision uniformly. It enters the partially committed transaction state when processing is complete at each site and waits for all other transactions to enter their partially committed states. It begins to commit when it receives the message that all the sites are ready to commit. Either all sites commit or none of them commit within a distributed system.

The various protocols of distributed commit are –

• one-phase commit
• Two-phase commit
• Three-phase commit

Distributed One-phase Commit

The simplest commit protocol is a distributed one-phase commit. Let's take into consideration that there is a control site and a variety of slave sites where the transaction is being carried out. The distributed commit measures are −

• It sends a 'DONE' message to the controlling site after each slave has completed its transaction locally.
• The slaves are waiting for a "Commit" or "Abort" response from the site they control. This waiting time is called the vulnerability window.
• If each slave receives a "DONE" message from the control site, it makes a decision to commit or abort. This is called the Point of Commit. Then, it sends all the slaves this message.
• A slave either commits or aborts on receiving this message and then sends an acknowledgment message to the controlling site.

Distributed Two-phase Commit

Two-phase commit distribution reduces the vulnerability of one-phase commit protocols. The steps taken in the 2 steps are as follows-

Phase 1: Prepare Phase

• It sends a 'DONE' message to the controlling site after each slave has completed its transaction locally. When all slaves receive a "DONE" message from the controlling site, it sends a "Prepare" message to the slaves.
• The slaves vote on whether or not they really want to commit themselves. "If a slave wants to commit, it sends a message which is" Ready.
• "A slave who doesn't want to commit sends a message that is" Not Ready. If the slave has conflicting concurrent transactions or there is a timeout, this can occur.

Phase 2: Commit/Abort Phase

• "After all the slaves got the" Ready "message from the control site-
  • The control site sends the slaves a "Global Commit" message.
  • The transaction is used by the slaves and a "Commit ACK" message is sent to the control site.
  • It considers the transaction as committed when the controlling site receives the "Commit ACK" message from all the slaves.
• The first "Not Ready" message from any slave has been received from the control site-
  • A "Global Abort" message is sent to the slaves by the controlling site.
  • The transaction is abort by the slaves and the "Abort ACK" message is sent to the control site.
  • When all the slaves receive the "Abort ACK" message from the controlling site, it considers the transaction to be aborted.

Distributed Three-phase Commit

The steps in the three-phase distributed commit are as follows:

Phase 1: Prepare Phase

The steps are the same as in the two-phase commit distribution.

Phase 2: Prepare to Commit Phase

• A "Enter Prepared State" broadcast message is issued by the controlling site.
• In response, the slave sites vote 'OK'.

Phase 3: Commit / Abort Phase

The steps are the same as a two-phase commit, except that no message is needed for "Commit ACK"/"Abort ACK".