Three-phase commit protocol: Difference between revisions

Revision as of 18:43, 22 April 2020

Latest revision as of 20:34, 14 December 2024

(15 intermediate revisions by 12 users not shown)

Line 1:

{{Short description|Distributed algorithm}}

In [[computer networking]] and distributed [[database]]s, the '''three-phase commit protocol''' ('''3PC''')<ref name=3PC>{{cite techreporttech report

| last = Skeen

| first = Dale

Line 6 ⟶ 7:

| institution = Department of Computer Science, Cornell University

| url = https://ecommons.cornell.edu/handle/1813/6323

}}</ref> is a [[distributed algorithm]] whichthat letsensures all nodes in a [[distributed system|system]] agree to [[Commit (data management)|commit]] or abort a [[database transaction|transaction]]. It isimproves a refinement ofupon the [[two-phase commit protocol]] (2PC) whichby iseliminating morethe resilientpossibility toof failuresindefinite blocking caused by a specific type of failure during the commit phase.

==Motivation==

Line 15 ⟶ 16:

==Solution==

The pre-commit phase introduced above helps usthe system to recover from the case when a participant failure or both the coordinator and a participant node failurefailed during the commit phase. When the recovery coordinator takes over after the coordinator failurefailed during a commit phase of [[two-phase commit]], the new pre-commit comes handy as follows: On querying participants, if it learns that some nodes are in commit phase then it assumes that the previous coordinator before crashing has made the decision to commit. Hence it can shepherd the protocol to commit. Similarly, if a participant says that it doesn’thad receivenot received a PrepareToCommit message, then the new coordinator can assume that the previous coordinator failed even before it completed the PrepareToCommit phase. Hence it can safely assume that no other participant would havehas committed the changes, and hence safely abort the transaction.

==Extensions==

Using Skeen's original three-phase commit protocol, it is possible that a quorum becomes connected without being able to make progress (this is not a deadlock situation; the system will still progress if the network partitioning is resolved). Keidar and Dolev's E3PC<ref name=E3PC>{{cite journal|last=Keidar|first=Idit|author1-link=Idit Keidar|author2=Danny Dolev |title=Increasing the Resilience of Distributed and Replicated Database Systems|journal= Journal of Computer and System Sciences|volume=57|issue=3|date=December 1998|pages=309–324|

url=httphttps://webeeiditkeidar.technion.ac.ilcom/wp-content/uploads/~idishfiles/Abstracts/jcss.html|doi=10.1006/jcss.1998.1566|doi-access=free}}</ref> refines Skeen's three-phase commit protocol and solves this problem in a way which *''always*'' allows a quorum to make progress.

==Disadvantages==

[[Three-phase commit]] assumes a network with bounded delay and nodes with bounded response times; In most practical systems with unbounded network delay and process pauses, it cannot guarantee atomicity. The other drawback of the protocol is it requires at least three round trips to complete, needing a minimum of three round trip times (RTTs). This is potentially a long latency to complete each transaction.

==References==

Line 29 ⟶ 30:

==See also==

*[[Two-phase commit protocol]]

*[[Paxos algorithm]]

[[Category:Transaction processing]]