Distributed DBMS Commit Protocols - Distributed DBMS

What are Commit Protocols in Distributed DBMS?

Generally the transaction manager needs to pass the commit decision to the recovery manager to commit a transaction in local database system. In distributed database system, the message to commit a transaction is sent by the transaction manager to all the servers of the multiple sites where the transaction is executed. At each site, the transaction after completing the processing reaches the partially committed transaction state and here it waits for the other transactions to reach the partially committed state. A message is received stating that all the sites are ready for commit, then the process of commit starts and thus either all the sites commit or none of the sites commit in distributed database system.

There are different types of distributed commit protocols. They are -

• One-phase commit
• Two-phase commit
• Three-phase commit

Distributed One-phase Commit

One of the simplest commit protocols is the distributed one-phase commit protocol. For instance, consider a controlling site and different number of slave sites at which the transaction is executed. The distributed commit has the following steps -

• A “DONE” message is sent to the controlling site once each of the slave complete its transactions.
• The slaves need to wait for “Commit” or “Abort” message from the controlling site, and the waiting time is known as window of vulnerability.
• When “DONE” message is received by the controlling site from each of the slaves, the decision to commit or abort is made, which is known as commit point. The message is sent to all the slaves.
• Once the message is received, the transaction is either committed or aborted by the slave and a acknowledgment message is sent to the controlling site.

Distributed Two-phase Commit

The vulnerability of one-phase commit protocol is reduced by the distributed two-phase commit. The two-phase commit has the following steps -

Phase 1: Prepare Phase

• A “DONE” message is sent to the controlling site by each of the slave when the transaction is completed locally. On receiving the message from all slaves, a “Prepare” message is sent by the controlling site to the slaves.
• The decision to commit to not is done by voting by the slaves. A “Ready” message is sent if the slave desires to commit.
• A “Not Ready” message is sent if the slave does not desire to commit. They may be either because of the conflicting concurrent transactions or because of timeout.

Phase 2: Commit/Abort Phase

• Once the “Ready” message is received by the controlling site from all the slaves -

1. A “Global Commit” message is sent by the controlling site to the slaves.
2. The transaction is applied by the slaves and a “Commit ACK” message is sent to the controlling site.
3. When the “Commit ACK” message is received by the controlling site from all the slaves, the transaction is considered as committed.

• When the “Not Ready” message is received by the controlling sites from any of the slaves -

1. A “Global Abort” message is sent by the controlling site to the slaves.
2. The transaction is aborted by the slaves and a “Abort ACK” message is sent to the controlling site.
3. When the “Abort ACK” message is received by the controlling site from all the slaves, the transaction is considered as aborted.

Distributed Three-phase Commit

The following are the steps involved in distributed three-phase commit -

Phase 1: Prepare Phase

The steps are similar to that of distributed twp-phase commit.

Phase 2: Prepare to Commit Phase

• A broadcast message stating “Enter Prepared State” is issued by the controlling site.
• The slave sites vote “OK” in response.

Phase 3: Commit / Abort Phase

The steps are similar to that of two-phase commit only difference being that the message of “Commit ACK”/”Abort ACK” is not required.