Tech Insights — Two-phase Commit Protocol for Distributed Transactions

Key Components for Implementing Distributed Transactions

Typical Two-phase Commit Protocol

  1. The TC writes a local <Prepare T> log and persists it. The TC sends a "Prepare T" message to all participants.
  2. Each participant TM receives the “Prepare T” message and decides whether to commit the transaction based on its own situation:
  • If a TM decides to commit the transaction, it writes a <Ready T> log and persists it, and then sends a "Ready T" message to the TC.
  • 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 all participants respond with a “Ready T” message, the TC writes a <Commit T> log and persists it, and then sends a "Commit T" message to all participants.
  • 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

  • If a participant fails before it sends a “Ready T” message, the TC considers that the node has aborted the transaction and starts the abortion process.
  • 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 a <Commit T> log, it indicates that the transaction has been committed, and the participant runs the REDO(T) command.
  • 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 <Commit T> logs) have committed the transaction, it indicates that the transaction T must be committed.
  • If one or more participants (including the <Abort T> logs) have aborted the transaction, it indicates that the transaction T must be aborted.
  • If one or more participants (not including the <Ready T> logs) are not in the ready state, it indicates that no global consensus has been reached on whether to commit the transaction or not. There are two options: (1) The participants wait for the TC to recover. (2) The participants abort the transaction. The latter option is selected in most cases to decrease the duration of resource occupation.
  • 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

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
Alibaba Cloud

Alibaba Cloud

Follow me to keep abreast with the latest technology news, industry insights, and developer trends. Alibaba Cloud website:https://www.alibabacloud.com