Three Phase Commit Protocol

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. Note - 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.