Tech Insights — Two-phase Commit Protocol for Distributed Transactions

Key Components for Implementing Distributed Transactions

Standalone systems implement local transactions through transaction managers (TMs). Distributed systems coordinate TMs of multiple nodes to collectively commit success or failure. Therefore, transaction coordinators (TCs) are required. A distributed transaction system mainly consists of these two subsystems, which are also called the participant and the coordinator based on their roles in transaction execution.

Typical Two-phase Commit Protocol

The process of two-phase commit is simple. When a distributed transaction T is completed, that is, all the nodes that have executed the transaction inform the TC of the execution completion, the TC starts the process of two-phase commit.

  1. Each participant TM receives the “Prepare T” message and decides whether to commit the transaction based on its own situation:
  • If a TM decides not to commit the transaction, it writes an <Abort T> log and persists it, and sends an "Abort T" message to the TC. Then, the TM enters the transaction abortion process locally.
  • If the TC receives an “Abort T” response from at least one participant, or if any participant fails to respond within the timeout period, the TC writes a <Abort T> log, and then sends an "Abort T" message to all participants.

Exception Handling in 2PC

The normal 2PC process is simple. However, various exceptions in distributed systems must be considered, such as node failures and network partitioning.

  • If a participant fails after it sends a “Ready T” message, it indicates that the participant has persisted the local transaction. The TC ignores the participant failure and proceeds with the transaction process.
  • If the logs include an <Abort T> log, it indicates that the transaction has failed, and the participant runs the UNDO(T) command.
  • If the logs include a <Ready T> log, the participant P communicates with other nodes to query the current transaction state.
  • If the TC is normal, it informs the participant P that the transaction has been committed or aborted, and the participant runs the REDO(T) or UNDO(T) command accordingly.
  • If the TC is abnormal, the participant P communicates with other participants to query the transaction state.
  • If other participants receive the message and know whether the transaction is committed or aborted, they must reply to the participant P with the transaction state.
  • If no participant knows the transaction state due to reasons such as destroyed context or its own pending status, the transaction can neither be committed nor aborted. The participant P must regularly communicate with other nodes to query the transaction state until it receives an answer. This is one of the worst scenarios in the 2PC protocol.
  • If the logs do not contain any of the preceding logs, it indicates that the participant fails before it sends a “Ready T” message to the TC. If the TC does not receive any response from the participant, it aborts the transaction due to timeout. If this is the case, the participant must abort the transaction during the recovery process.
  • If one or more participants (including the <Abort T> logs) have aborted the transaction, it indicates that the transaction T must be aborted.
  • If all participants are in the ready state without <Commit T> or <Abort T> logs, no participant knows the current transaction state, so the participants must wait for the TC to recover. In fact, even if there are <Commit T> and <Abort T> logs, log query is time-consuming, and log collection is another consideration. Again, this is one of the worst scenarios in the 2PC protocol.

Solutions for Mitigating the 2PC Blocking Problem

The three-phase commit protocol (3PC) is an extension of the 2PC protocol to solve the blocking problem, but it has also introduced other problems. It addresses the blocking problem by introducing a timeout mechanism: If a participant has sent a PreCommit request but does not receive the final DoCommit request from the TC, the participant must wait for the transaction to be automatically committed upon timeout. Obviously, this will cause consistency problems. For example, if the TC goes down when it receives a PreCommit failure from a participant and intends to send an abort request to other participants, the corresponding distributed transaction is supposed to fail. However, some participants may commit it due to timeout.

Original Source:

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store