Three-phase commit protocol
From Wikipedia, the free encyclopedia
In computer networking and databases, the three-phase commit protocol (3PC) is a distributed algorithm which lets all nodes in a distributed system agree to commit a transaction. Unlike the two-phase commit protocol (2PC) however, 3PC is non-blocking. Specifically, 3PC places an upper bound on the amount of time required before a transaction either commits or aborts. This property ensures that if a given transaction is attempting to commit via 3PC and holds some resource locks, it will release the locks after the timeout.
3PC was originally described by Dale Skeen and Michael Stonebraker in their paper, "A Formal Model of Crash Recovery in a Distributed System." In that work, they modeled 2PC as a system of non-deterministic finite state automata and proved that it is not resilient to a random single site failure. The basic observation is that in 2PC, while one site is in the "prepared to commit" state, the other may be in either the "commit" or the "abort" state. From this analysis, they developed 3PC to avoid such states and it is thus resilient to such failures.
Contents |
[edit] Protocol Description
In describing the protocol, we use terminology similar to that used in the two-phase commit protocol. Thus we have a single coordinator site leading the transaction and a set of one or more cohorts being directed by the coordinator.
[edit] Coordinator
- The coordinator receives a transaction request. If there is a failure at this point, the coordinator aborts the transaction (i.e. upon recovery, it will consider the transaction aborted). Otherwise, the coordinator sends a start transaction message to the cohorts and moves to the waiting state.
- If there is a failure, timeout, or if the coordinator receives a will not start transaction message in the waiting state, the coordinator aborts the transaction and sends an abort message to all cohorts. Otherwise the coordinator will receive will start transaction messages from all cohorts within the time window, so it sends commit messages to all cohorts and moves to the prepared state.
- If the coordinator fails in the prepared state, it will move to the commit state. However if the coordinator times out while waiting for an acknowledgement from a cohort, it will abort the transaction. In the case where all acknowledgements are received, the coordinator moves to the commit state as well.
[edit] Cohort
- The cohort receives a start transaction message from the coordinator. If the cohort agrees it sends a will start transaction message to the coordinator and moves to the prepared state. Otherwise it sends a will not start transaction message and aborts. If there is a failure, it moves to the abort state.
- In the prepared state, if the cohort receives an abort message from the coordinator, fails, or times out waiting for a commit, it aborts. If the cohort receives a commit message, it sends an ack message back and commits.
[edit] Disadvantages
The main disadvantage to this algorithm is that it cannot recover in the event the network is segmented in any manner. Simply put, if the network of nodes were to be separated into two equal halves, each half would continue on its own.
[edit] References
- Skeen, D. (May 1983). "A Formal Model of Crash Recovery in a Distributed System". IEEE Transactions on Software Engineering 9 (3): 219-228.
- See http://ei.cs.vt.edu/~cs5204/fall99/distributedDBMS/sreenu/3pc.html (shows automata)