Two-phase commit protocol

From Wikipedia, the free encyclopedia

(Redirected from Two-phase commit)

Jump to: navigation, search

In computer networking and databases, the two-phase commit protocol (2PC) is a distributed algorithm that lets all nodes in a distributed system agree to commit a transaction. The protocol results in either all nodes committing the transaction or aborting, even in the case of network failures or node failures. However, the protocol will not handle more than one random site failure at a time [1]. The two phases of the algorithm are the commit-request phase, in which the coordinator attempts to prepare all the cohorts, and the commit phase, in which the coordinator completes the transactions.

Contents

[hide]
  • 1Assumptions
  • 2Basic algorithm
  • 2.1Commit-request phase
  • 2.2Commit phase
  • 2.2.1Success
  • 2.2.2Failure
  • 3Disadvantages
  • 4Distributed two-phase commit protocol
  • 4.1Common architecture
  • 4.2Tree two-phase commit protocol
  • 5References
  • 6See also
  • 7External links

[edit]Assumptions

The protocol works in the following manner: one node is designated the coordinator, which is the master site, and the rest of the nodes in the network are designated the cohorts. The protocol assumes that there is stable storage at each node with a write-ahead log, that no node crashes forever, that the data in the write-ahead log is never lost or corrupted in a crash, and that any two nodes can communicate with each other. The last assumption is not too restrictive, as network communication can typically be rerouted. The first two assumptions are much stronger; if a node is totally destroyed then data can be lost.

The protocol is initiated by the coordinator after the last step of the transaction has been reached. The cohorts then respond with an agreement message or an abort message depending on whether the transactions has been processed successfully at the cohort.

[edit]Basic algorithm

[edit]Commit-request phase

  1. The coordinator sends a query to commit message to all cohorts.
  2. The coordinator waits until it has a message from each cohort.
  3. The cohorts execute the transaction up to the point where they will be asked to commit. They each write an entry to their undo log and an entry to their redo log.
  4. Each cohort replies with an agreement message (cohort votes Yes to commit), if the transaction succeeded, or an abort message (cohort votes No, not to commit), if the transaction failed.

[edit]Commit phase

[edit]Success

If the coordinator received an agreement message from all cohorts during the commit-request phase:

  1. The coordinator sends a commit message to all the cohorts.
  2. Each cohort completes the operation, and releases all the locks and resources held during the transaction.
  3. Each cohort sends an acknowledgment to the coordinator.
  4. The coordinator completes the transaction when acknowledgments have been received.
[edit]Failure

If any cohort sent an abort message during the commit-request phase:

  1. The coordinator sends a rollback message to all the cohorts.
  2. Each cohort undoes the transaction using the undo log, and releases the resources and locks held during the transaction.
  3. Each cohort sends an acknowledgement to the coordinator.
  4. The coordinator completes the transaction when acknowledgements have been received.

[edit]Disadvantages

The greatest disadvantage of the two-phase commit protocol is the fact that it is a blocking protocol. A node will block while it is waiting for a message. This means that other processes competing for resource locks held by the blocked processes will have to wait for the locks to be released. A single node will continue to wait even if all other sites have failed. If the coordinator fails permanently, some cohorts will never resolve their transactions. This has the effect that resources are tied up forever. The algorithm can block indefinitely in the following way: if a cohort has sent an agreement message to the coordinator, it will block until a commit or rollback is received. If the coordinator is permanently down, the cohort will block indefinitely, unless it can obtain the global commit/abort decision from some other cohort. When the coordinator has sent "Query-to-commit" to the cohorts, it will block until all cohorts have sent their local decision. Yet, if a cohort is permanently down, the coordinator will not block indefinitely: Since the coordinator is the one to decide whether the decision is 'commit' or 'abort' permanent blocking can be avoided by introducing a timeout: If the coordinator has not received all awaited messages when the timeout is over it will decide for 'abort'. This conservative behaviour of the protocol is another disadvantage: It is biased to the abort case rather than the complete case.

A lot of database research has been done on ways to get most of the benefits of the two-phase commit protocol without the costs.

[edit]Distributed two-phase commit protocol

[edit]Common architecture

In many cases the 2PC protocol is utilized in distributed environments. The protocol is easily distributed in a network by implementing multiple dedicated 2PC components similar to each other, typically named Transaction Managers (TMs; also referred to as 2PC agents), that carry out the protocol's execution for each transaction. The databases involved with a distributed transaction, the participants, both the coordinator and cohorts, register to close TMs (typically residing on respective same network nodes as the participants) for terminating that transaction using 2PC. Each distributed transaction has an ad hoc set of TMs, the TMs to which the transaction participants register. A leader, the coordinator TM exists for each transaction to coordinate 2PC for it, typically the TM of the coordinator database. However, the coordinator role can be transferred to another TM for performance or reliability reasons. Rather than exchanging 2PC messages among themselves, the participants exchange the messages with their respective TMs. The relevant TMs communicate among themselves to execute the 2PC protocol schema above, "representing" the respective participants, for terminating that transaction. With this architecture the protocol is fully distributed (does not need any central processing component or data structure), and scales up with number of network nodes (network size) effectively.

[edit]Tree two-phase commit protocol

A common variant of 2PC in a distributed system with better communication efficiency is the Tree 2PC protocol. In this variant the coordinator is the root ("top") of a communication tree (inverted tree), while the cohorts are the other nodes. Messages from the coordinator are propagated "down" the tree, while messages to the coordinator are "collected" by a cohort from all the cohorts below it, before it sends the appropriate message "up" the tree (except an abort message, which is propagated "up" immediately upon receiving it, or if this cohort decided to abort).

The Dynamic two-phase commit (Dynamic two-phase commitment, D2PC) protocol is a variant of Tree 2PC with no predetermined coordinator. Agreement messages are sent by each leaf upon completion of the transaction (becoming ready). The coordinator is determined dynamically by a racing agreement of messages at the node where the messages collide. Messages may collide either at a transaction tree node, or at an edge. In the latter case one of the two edge's nodes is elected as a coordinator. D2PC is time optimal (among all the instances of a specific transaction tree, and any specific Tree 2PC protocol implementation; all instances have the same tree; each instance has a different node as coordinator): it commits the coordinator and each cohort in minimum possible time, allowing a prompt release of locked resources.