3PC (Three-Phase Commit)

Overview

3PC (Three-Phase Commit) is the three-phase commit protocol, an improved version of the Two-Phase Commit protocol (2PC). 3PC further divides the transaction request process of 2PC into two stages, forming a distributed transaction processing protocol composed of three stages: CanCommit, PreCommit, and doCommit.

Protocol Stages in Detail

1. CanCommit Phase (Inquiry Phase)

  • The coordinator sends a CanCommit request to all participants
  • Participants check their own status and determine if they can execute the transaction
  • Participants reply with Yes/No response (ACK/NACK)
  • The coordinator decides whether to proceed to the next phase based on the response

2. PreCommit Phase (Preparation Phase)

  • If all participants reply Yes, the coordinator sends a PreCommit request
  • Participants execute transaction operations but do not commit, writing undo/redo logs
  • Participants lock relevant resources to ensure the transaction can be rolled back
  • Participants reply with Ack to confirm preparation is complete

3. doCommit Phase (Commit Phase)

  • After receiving all Acks, the coordinator sends a doCommit request
  • Participants formally commit the transaction
  • Participants release resource locks
  • Participants reply with Ack to confirm commit is complete

Improved Advantages

Compared to 2PC, the main improvements of 3PC include:

  1. Added CanCommit phase to verify participant status in advance
  2. Reduced blocking risk (introduced timeout mechanism)
  3. Improved system availability (partial failures can continue running)
  4. Reduced the impact of coordinator single point of failure

Limitations

Although 3PC has improvements, the following problems still exist:

  • Network partitioning may lead to data inconsistency
  • Implementation complexity is higher than 2PC
  • Performance overhead is relatively large
  • Cannot completely solve all distributed consistency problems

Phase One: CanCommit

Transaction Inquiry: The coordinator sends a canCommit request containing transaction content to all participants, asking if they can execute the transaction commit operation, and starts waiting for responses from participants.

Participants Feedback Transaction Inquiry Response: After participants receive the canCommit request containing transaction content from the coordinator, under normal circumstances, if they believe they can successfully execute the transaction, they feedback Yes and enter a preparatory state; otherwise, they feedback No.

Phase Two: PreCommit

After the coordinator receives responses from participants, there are two types of execution operations based on the results: execute transaction pre-commit or abort the transaction.

If all participants feedback Yes, the coordinator will execute transaction pre-commit.

Send Pre-Commit Request: The coordinator sends a preCommit request to all participant nodes and enters the prepared phase.

Transaction Pre-Commit: After participants receive the preCommit request, they execute transaction operations and record Undo and Redo information in the transaction log.

Participants Feedback Transaction Execution Results to Coordinator: If a participant successfully executes the transaction operation, they feedback ACK. If any participant feedbacks No, or if the coordinator cannot receive responses from all participants after timeout, the transaction is aborted.

Aborting the transaction is also divided into two steps:

  • Send abort request: The coordinator sends an abort request to all participants
  • Abort transaction: Whether participants receive the abort request from the coordinator or timeout while waiting for the coordinator’s request, they will abort the transaction

Phase Three: doCommit

This phase handles the actual transaction commit or completes the transaction rollback. There are two situations:

Scenario One: Execute Transaction Commit

  • Send commit request: At this stage, assuming the coordinator is in normal working state and has received ACK responses from all participants, it will transition from pre-commit state to commit state and send a doCommit request to all participants
  • Transaction commit: After participants receive the doCommit request, they formally execute the transaction commit operation and release all transaction resources occupied during the transaction execution.
  • Feedback transaction commit results: After participants complete the transaction commit, they send an ACK response to the coordinator
  • Complete transaction: After the coordinator receives ACK messages from all participants, the transaction is completed.

Scenario Two: Abort Transaction

  • Send abort request: The coordinator sends an abort request to all participant nodes.
  • Transaction rollback: After participants receive the abort request, they execute the transaction rollback based on the recorded Undo information and release all resources occupied during the transaction execution after completing the rollback
  • Feedback transaction rollback results: After participants complete the transaction rollback, they send an ACK message to the coordinator
  • Abort transaction: After the coordinator receives ACK messages from all participants, the transaction is aborted.

Note: Once entering phase three, two types of failures may occur:

  • The coordinator出现问题
  • Network failure between coordinator and participants

If either situation occurs, it will ultimately lead to participants not receiving the doCommit request or abort request. In response to this situation, participants will continue with transaction commit after timeout.

2PC vs 3PC Comparison

Timeout Mechanism Improvement

In the 2PC (Two-Phase Commit) protocol, only the coordinator has a timeout mechanism. This means when the coordinator does not receive a response from participants within the specified time, it defaults to transaction execution failure. However, 3PC (Three-Phase Commit) has made important improvements:

Participant Timeout Mechanism:

  • Each participant sets a timeout timer
  • If the coordinator’s instructions are not received for a long time during the CanCommit or PreCommit phases (such as network partitioning or coordinator failure)
  • Participants will automatically execute local Commit operations after timeout to release resources

Three-Phase Design Advantages

3PC provides better reliability through three-phase design:

1. CanCommit Phase:

  • The coordinator asks participants if they have conditions to execute the transaction
  • Participants check resource availability but do not lock resources
  • Similar to a “pre-check” phase

2. PreCommit Phase:

  • Core buffer phase
  • The coordinator sends PreCommit requests after receiving Yes responses from all participants
  • Participants execute transaction operations but do not commit yet
  • This phase ensures all participants’ status is consistent

3. DoCommit Phase:

  • Final commit phase
  • The coordinator confirms all participants have completed PreCommit before sending commit instructions

Limitations

Despite the above improvements, 3PC still has the following problems:

1. Possibility of Data Inconsistency:

  • If network partitioning occurs during the DoCommit phase
  • Some participants may not receive commit instructions
  • Leading to some system nodes being committed while others are not

2. Performance Loss:

  • Additional communication phase increases latency
  • Not suitable for latency-sensitive application scenarios

3. Implementation Complexity:

  • Requires more complex state machines to handle exceptions at each phase
  • Increases system development and maintenance costs