Two Phase Commit Protocol

Two-Phase Commit Protocol

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 −

Distributed one-phase commit is the simplest commit protocol.
Let us consider that there is a controlling 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 controlling site.
The slaves wait for the “Commit” or “Abort” message from the controlling site. This waiting time is called the window of vulnerability.
When the controlling site receives the “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 acknowledgment message to the controlling site.

A two-phase commit is a standardized protocol that ensures that a database commit is implementing in the situation where a commit operation must be broken into two separate parts.
In the two-phase commit protocol, there are two phases (that’s the reason it is called Two-phase commit protocol) involved.

In this phase, a coordinator (either a separate node or the node initiating the transaction) makes a request to all the participating nodes, asking them whether they are able to commit the transaction.
They either return yes or no in the response.
They return yes if they can successfully commit the transaction or no if they unable to do so.

In the second phase, the coordinator decides based on the votes whether to send the commit or abort request to the participating nodes.
This phase is called the commit phase.

If all the participating nodes said yes, then commit request is sent to all the nodes
If any of the participating nodes said no, then abort request is sent to all the nodes

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

After each slave has locally completed its transaction, it sends a “DONE” message to the controlling site. When the controlling 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 conflicting concurrent transactions or there is a timeout.

After the controlling site has received “Ready” message from all the slaves −
The controlling site sends a “Global Commit” message to the slaves.
The slaves apply the transaction and send a “Commit ACK” message to the controlling site.
When the controlling site receives “Commit ACK” message from all the slaves, it considers the transaction as committed.
After the controlling site has received the first “Not Ready” message from any slave −
The controlling site sends a “Global Abort” message to the slaves.
The slaves abort the transaction and send a “Abort ACK” message to the controlling site.
When the controlling site receives “Abort ACK” message from all the slaves, it considers the transaction as aborted.

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