Two-phase commit protocol

Commit protocols regulate the commit (commit ) of data to be modified by a (distributed) transaction, for example, in a database management system.

Need and requirements

The desirable properties of ( distributed ) transactions are defined by ACID. The commit protocol is responsible for ensuring these properties. Depending on the commit protocol must not be mandatory satisfies all properties.

Basic principle

In order to fulfill their respective requirements describe Commit protocols must communicate as participating in a transaction processes through a coordinator to each other as information logged ( logged ), and how, finally, the affected data is committed. Various error conditions are caught by the protocol, such as a crash of the coordinator during a phase ( depending on the protocol ).

Variants

In distributed systems, a transaction often spans multiple processes ( in English, in this context referred to as agents ) that modify together and interdependent data. To ensure atomicity here a distributed commit protocol is required.

Two - phase commit protocols

The best-known and standardized through X / Open XA method is the so-called "two- phase commit " or two- phase commit ( 2PC ). It brings a coordinator (usually the process that initiates the commit ) in the first phase of the protocol agreement or disagreement with the formalization of the data changes all the processes involved (even " Voting Phase "). Only when all participants agree, the coordinator decides to " commit ", otherwise the decision is "rollback" (Reset). The decision is made, inform the coordinator in the second phase (" commit " phase ) of the Protocol, the participants of the outcome. According to this common result, the entire transaction is rolled back, all or part of transactions are carried out to a successful conclusion by the temporarily locked resources are released again either.

Algorithm

During both phases, the following messages are exchanged between the participants:

When the coordinator of all the participants got a ready message:

If at least one of the participants failed to send:

In the two -phase commit is the fundamental problem that participants are temporarily blocked. This happens whenever a party has notified its local " Commit" decision to the coordinator. Thereafter, the user waits on the global ( common ) decision. This is especially problematic if the coordinator has failed in the meantime. In this situation, the participants can share neither the locked resources, or reset the local transaction. At most, the participant can bring the global commit decision by another participant in experience.

Correctness

The 2PC protocol guarantees the correctness even fail if one or more computers or when network partitions occur, so that the communication between runnable computers is prohibited. Correctness in this context means: It can not happen that a transaction at different participants come to different results.

Three - phase commit protocols

To reduce the number of necessary logging operations, the number of required messages as well as to increase the robustness in the literature numerous variants of the 2PC protocol are discussed. Thus, the purpose about the so-called three -phase commit protocol ( 3PC ) aims to reduce the risk of blockage. To an increase in the number of rounds of message is required in order for a temporary failure of the coordinator, the protocol may be performed with a new coordinator to the end.