Distributed DBMS - Commit Protocols

In a local database system, for committing a transaction, the transaction manager has to only convey the decision to commit to the recovery manager. However, in a distributed system, the transaction manager should convey the decision to commit to all the servers in the various sites where the transaction is being executed and uniformly enforce the decision. When processing is complete at each site, it reaches the partially committed transaction state and waits for all other transactions to reach their partially committed states. When it receives the message that all the sites are ready to commit, it starts to commit. In a distributed system, either all sites commit or none of them does.

The different distributed commit protocols are −

One-phase commit

Two-phase commit

Three-phase commit

Distributed One-phase Commit

Distributed one-phase commit is the simplest commit protocol. Let us consider that there is a controlpng site and a number of slave sites where the transaction is being executed. The steps in distributed commit are −

After each slave has locally completed its transaction, it sends a “DONE” message to the controlpng site.

The slaves wait for “Commit” or “Abort” message from the controlpng site. This waiting time is called window of vulnerabipty.

When the controlpng site receives “DONE” message from each slave, it makes a decision to commit or abort. This is called the commit point. Then, it sends this message to all the slaves.

On receiving this message, a slave either commits or aborts and then sends an acknowledgement message to the controlpng site.

Distributed Two-phase Commit

Distributed two-phase commit reduces the vulnerabipty of one-phase commit protocols. The steps performed in the two phases are as follows −

Phase 1: Prepare Phase

After each slave has locally completed its transaction, it sends a “DONE” message to the controlpng site. When the controlpng site has received “DONE” message from all slaves, it sends a “Prepare” message to the slaves.

The slaves vote on whether they still want to commit or not. If a slave wants to commit, it sends a “Ready” message.

A slave that does not want to commit sends a “Not Ready” message. This may happen when the slave has confpcting concurrent transactions or there is a timeout.

Phase 2: Commit/Abort Phase

After the controlpng site has received “Ready” message from all the slaves −

The controlpng site sends a “Global Commit” message to the slaves.

The slaves apply the transaction and send a “Commit ACK” message to the controlpng site.

When the controlpng site receives “Commit ACK” message from all the slaves, it considers the transaction as committed.

After the controlpng site has received the first “Not Ready” message from any slave −

The controlpng site sends a “Global Abort” message to the slaves.

The slaves abort the transaction and send a “Abort ACK” message to the controlpng site.

When the controlpng site receives “Abort ACK” message from all the slaves, it considers the transaction as aborted.

Distributed Three-phase Commit

The steps in distributed three-phase commit are as follows −

Phase 1: Prepare Phase

The steps are same as in distributed two-phase commit.

Phase 2: Prepare to Commit Phase

The controlpng site issues an “Enter Prepared State” broadcast message.

The slave sites vote “OK” in response.

Phase 3: Commit / Abort Phase

The steps are same as two-phase commit except that “Commit ACK”/”Abort ACK” message is not required.