Three-Phase Commit (3PC) Protocol is an extension of the Two-Phase Commit (2PC) Protocol that avoids blocking problem under certain assumptions. In particular, it is assumed that no network partition occurs, and not more than k sites fail, where we assume ‘k’ is predetermined number. With the mentioned assumptions, protocol avoids blocking by introducing an extra third phase where multiple sites are involved in the decision to commit.
Instead of directly noting the commit decision in its persistent storage, the coordinator first ensures that at least ‘k’ other sites know that it intended to commit transaction.
In a situation where coordinator fails, remaining sites are bound to first select new coordinator. This new coordinator checks status of the protocol from the remaining sites. If the coordinator had decided to commit, at least one of other ‘k’ sites that it informed will be up and will ensure that commit decision is respected. The new coordinator restarts third phase of protocol if any of rest sites knew that old coordinator intended to commit transaction. Otherwise, new coordinator aborts the transaction.
Drawback of the Three-Phase Commit Protocol :
While 3PC protocol has desired property of not blocking unless ‘k’ sites fail, it has drawback that partitioning of network may appear to be same as more than ‘k’ sites failing, which would lead to blocking. The protocol also has to be implemented carefully to ensure that network partitioning does not result in inconsistencies, where transaction is committed in one partition and aborted in another. Because of its overhead, 3PC protocol is not widely used.
The difference between Three-Phase Control Protocol and Two-Phase Control Protocol can be understood by the following figures.
Dissemination Phase :
It is introduced above helps the user to deal with the cases as when either a participant failure or both coordinator and participant node failure during the commit phase.
The recovery coordinator when it takes over after coordinator failure during Phase-2 of the previous Two-Phase Commit Protocol the new additional phase comes handy as follows.
On querying participants, if it learns that some nodes are in the commit phase, it then assumes that previous coordinator before crashing has made decision to commit.
Hence it can shepherd the protocol to commit. Similarly, if a participant responds that it doesn’t receive prepare to commit, then new coordinator can assume that previous coordinator failed even before it started the preparation to commit phase. Hence it can safely assume that no other participant would have committed any of changes and hence it can now safely abort the transaction.
Attention reader! Don’t stop learning now. Get hold of all the important CS Theory concepts for SDE interviews with the CS Theory Course at a student-friendly price and become industry ready.
- Two Phase Locking Protocol
- Two Phase Locking (2-PL) Concurrency Control Protocol | Set 3
- Difference between COMMIT and ROLLBACK in SQL
- Categories of Two Phase Locking (Strict, Rigorous & Conservative)
- Lock Based Concurrency Control Protocol in DBMS
- Graph Based Concurrency Control Protocol in DBMS
- Gossip Protocol in Cassandra
- Main difference between Timestamp protocol and Thomos write rule in DBMS
- Validation Based Protocol in DBMS
- Difference Between Two-Tier And Three-Tier database architecture
- Performing DataBase Operations in XAMPP
- Eventual vs Strong Consistency in Distributed Databases
- Difference between Open Source Database and Commercial Database
- Difference between MapR platform and Cloudera platform
If you like GeeksforGeeks and would like to contribute, you can also write an article using contribute.geeksforgeeks.org or mail your article to email@example.com. See your article appearing on the GeeksforGeeks main page and help other Geeks.
Please Improve this article if you find anything incorrect by clicking on the "Improve Article" button below.