Three-Phase Commit (3PC) Overview

The Two-Phase Commit protocol has a fundamental weakness: it can block indefinitely when the coordinator fails while participants are in the PREPARED state. This blocking problem motivated the development of the Three-Phase Commit (3PC) protocol, introduced by Dale Skeen in 1981.

3PC adds an additional intermediate phase between PREPARE and COMMIT, creating a buffer that allows participants to make progress even when the coordinator becomes unreachable. The key insight is that by introducing a pre-commit phase, participants gain enough information to safely resolve the transaction without the coordinator.

However, 3PC is not a silver bullet. While it eliminates blocking under certain failure assumptions, it introduces additional complexity, latency, and—critically—it cannot handle network partitions correctly. Understanding 3PC's design, benefits, and limitations provides essential insight into the fundamental trade-offs in distributed transaction protocols.

To understand 3PC, we must first deeply analyze why 2PC blocks and what properties would be needed to avoid blocking.

The Root Cause of 2PC Blocking:

In 2PC, when a participant enters the PREPARED state:

1. It has voted VOTE_COMMIT
2. It has promised to follow the coordinator's decision
3. It doesn't know if other participants voted COMMIT or ABORT
4. It doesn't know the coordinator's decision

If the coordinator fails, the participant is stuck. It cannot:

• Commit unilaterally: Other participants might have voted ABORT, and the coordinator decided ABORT
• Abort unilaterally: Other participants might have received GLOBAL_COMMIT and already committed

The problem is asymmetric information: from the PREPARED state, the participant cannot distinguish between a future COMMIT and a future ABORT.

The 3PC Solution: Add a Pre-Commit Phase

3PC inserts a PRE-COMMIT phase between PREPARED and COMMITTED:

1. Phase 1 (Can Commit?): Coordinator asks all participants if they can commit
2. Phase 2 (Pre-Commit): If all can commit, coordinator tells all to prepare to commit (PRE-COMMIT)
3. Phase 3 (Do Commit): Coordinator tells all to actually commit

The crucial property: Before any participant receives DO_COMMIT (and enters COMMITTED), all participants have received PRE_COMMIT (and entered PRE-COMMITTED state).

This means if the coordinator fails and any participant is in PRE-COMMITTED state, that participant knows:

• All participants voted to commit (otherwise we wouldn't have reached PRE-COMMIT)
• No participant has committed yet (Phase 3 hasn't happened)
• Either commit or abort is safe—if all remaining participants agree

This additional knowledge enables non-blocking termination.

Let's examine each phase of the 3PC protocol in rigorous detail.

Phase 1: Can Commit (Voting Phase)

This phase is essentially identical to 2PC's prepare phase:

1. Coordinator sends CAN_COMMIT message to all participants
2. Each participant determines if it can commit:
   • Checks constraints, resources, locks
   • If yes: replies YES_VOTE and enters UNCERTAIN state
   • If no: replies NO_VOTE and aborts locally
3. Coordinator collects all votes:
   • If all YES_VOTE: proceed to Phase 2
   • If any NO_VOTE or timeout: send ABORT to all and terminate

Important: At the end of Phase 1, if the coordinator hasn't received all YES_VOTEs, it aborts immediately. There is no ambiguity—the coordinator knows the transaction will abort.

Phase 2: Pre-Commit (Prepare to Commit Phase)

This is the new phase that distinguishes 3PC from 2PC:

1. Coordinator sends PRE_COMMIT message to all participants
2. Each participant receives PRE_COMMIT:
   • Writes durable log record indicating readiness
   • Enters PRE-COMMITTED state
   • Replies with ACK_PRE_COMMIT
3. Coordinator collects all acknowledgments:
   • If all acknowledge: proceed to Phase 3
   • If timeout: can still safely abort (no one has committed yet)

Critical Property: Receiving PRE_COMMIT tells a participant that:

• All participants voted YES (unanimous consent)
• The coordinator intends to commit
• But no participant has committed yet

This is the key insight: the PRE-COMMITTED state indicates consensus to commit without irrevocable commitment.

Phase 3: Do Commit (Commit Phase)

The final phase mirrors 2PC's commit phase:

1. Coordinator sends DO_COMMIT message to all participants
2. Each participant receives DO_COMMIT:
   • Makes changes permanent
   • Enters COMMITTED state
   • Replies with DONE
3. Coordinator collects confirmations:
   • Transaction complete when all DONE received

The Complete Message Flow:

Understanding the state machines for both coordinator and participant is essential for reasoning about 3PC's non-blocking properties.

Coordinator State Machine:

1. INITIAL: Transaction executing
2. WAITING: Sent CAN_COMMIT, waiting for votes
3. PRE-COMMITTING: All YES_VOTEs received, sent PRE_COMMIT, waiting for ACKs
4. COMMITTING: All PRE_COMMIT ACKs received, sent DO_COMMIT
5. COMMITTED: All DONE received, transaction complete
6. ABORTED: Abort decision made at any point

Participant State Machine:

1. INITIAL: Executing local operations
2. UNCERTAIN: Voted YES_VOTE, waiting for Phase 2 message
3. PRE-COMMITTED: Received PRE_COMMIT, ready to commit, waiting for DO_COMMIT
4. COMMITTED: Received DO_COMMIT, transaction completed
5. ABORTED: Received ABORT or decided to abort

The Key Non-Blocking Property:

Notice that in 3PC, before any participant reaches COMMITTED, all participants must pass through PRE-COMMITTED. This means:

• If coordinator fails and ANY participant is PRE-COMMITTED, all survivors know the intent was to commit
• If coordinator fails and NO participant is PRE-COMMITTED, all can safely abort
• There's no scenario where one participant is COMMITTED while another is only UNCERTAIN

The primary advantage of 3PC over 2PC is its non-blocking property under certain failure assumptions. Let's understand how this works.

The Termination Protocol:

When the coordinator fails and a participant times out waiting for a message, the participant initiates a termination protocol:

1. Elect a new coordinator from surviving participants
2. New coordinator polls all reachable participants for their states
3. Based on collected states, new coordinator decides:
   • If ANY participant is COMMITTED → Everyone should COMMIT
   • If ANY participant is ABORTED → Everyone should ABORT
   • If ANY participant is PRE-COMMITTED and none COMMITTED → Safe to COMMIT
   • If ALL participants are UNCERTAIN (none PRE-COMMITTED) → Safe to ABORT
   • If mix of UNCERTAIN and PRE-COMMITTED → COMMIT (PRE-COMMITTED means intent was commit)

Why This Works:

The key invariant that 3PC maintains is:

No participant can be in COMMITTED state while any other participant is in UNCERTAIN state.

This is because:

1. A participant enters PRE-COMMITTED only after receiving PRE_COMMIT
2. The coordinator sends PRE_COMMIT to all participants before sending any DO_COMMIT
3. A participant enters COMMITTED only after receiving DO_COMMIT
4. Therefore, if anyone is COMMITTED, everyone must have passed through PRE-COMMITTED

Contrast with 2PC:

In 2PC, a participant in PREPARED state (equivalent to UNCERTAIN) cannot know if another participant has committed. In 3PC, if any participant is merely UNCERTAIN, we know for certain that no participant is COMMITTED—enabling safe abort.

Let's trace through how 3PC handles various failure scenarios, comparing with 2PC behavior.

Scenario 5.1: Coordinator Fails After Receiving All YES_VOTEs, Before Sending PRE_COMMIT

In 2PC: All participants in PREPARED state, blocked forever In 3PC:

• All participants in UNCERTAIN state
• Timeout triggers termination protocol
• New coordinator finds all UNCERTAIN
• Decision: ABORT (safe, no one pre-committed)
• Transaction aborts, no blocking!

Scenario 5.2: Coordinator Fails After Sending Some PRE_COMMIT Messages

In 3PC:

• Some participants in PRE-COMMITTED state
• Some participants in UNCERTAIN state (didn't receive PRE_COMMIT)
• Termination protocol finds mix of PRE-COMMITTED and UNCERTAIN
• Decision: COMMIT (PRE-COMMITTED proves unanimous YES)
• All participants commit, no blocking!

Scenario 5.3: Coordinator Fails After Sending All PRE_COMMIT, Before Sending DO_COMMIT

In 3PC:

• All participants in PRE-COMMITTED state
• Termination protocol finds all PRE-COMMITTED
• Decision: COMMIT
• All participants commit, no blocking!

Scenario 5.4: Coordinator Fails After Sending Some DO_COMMIT Messages

In 3PC:

• Some participants in COMMITTED state
• Some participants in PRE-COMMITTED state
• Termination protocol finds at least one COMMITTED
• Decision: COMMIT
• Remaining participants commit

This scenario is similar to 2PC in the sense that the decision is already determined, but unlike 2PC, participants can resolve it themselves without waiting for coordinator recovery.

While 3PC eliminates blocking under crash failures, it has a critical vulnerability: network partitions can cause inconsistency. This is 3PC's most significant limitation.

The Dangerous Scenario:

1. All participants vote YES, reach UNCERTAIN state
2. Coordinator sends PRE_COMMIT to some participants
3. Network partition occurs, splitting participants:
   • Partition A: Contains coordinator and participants who received PRE_COMMIT (in PRE-COMMITTED state)
   • Partition B: Contains participants who didn't receive PRE_COMMIT (in UNCERTAIN state)
4. Both partitions believe they have quorum and can proceed
5. Partition A: Sees PRE-COMMITTED participants, decides COMMIT
6. Partition B: Sees only UNCERTAIN participants, decides ABORT
7. Result: INCONSISTENCY! Some committed, some aborted.

Why This Happens:

The termination protocol assumes that if no participant is PRE-COMMITTED, it's safe to abort. But during a partition:

• Partition B cannot see participants in Partition A who are PRE-COMMITTED
• Partition B sees only UNCERTAIN participants, believes abort is safe
• Meanwhile, Partition A sees PRE-COMMITTED participants and commits

The Fundamental Trade-off:

3PC's termination protocol assumes that all surviving participants can communicate with each other. With network partitions, this assumption breaks down. Each partition sees only a subset of participants and may make inconsistent decisions.

Quorum-Based Solutions:

Some 3PC variants use quorum-based voting to mitigate this:

• Require a majority of participants to agree on the decision
• Only the partition with a majority can make progress
• The minority partition must block

However, this reintroduces some blocking (though less than 2PC) and requires careful configuration of quorum sizes.

Let's systematically compare the two protocols across multiple dimensions to understand when each is appropriate.

When to Use 2PC:

• Network partitions are the primary failure concern
• Safety (never diverge) is more important than liveness (never block)
• Latency is critical (fewer round trips)
• The coordinator is highly available (replication, failover)
• Existing infrastructure supports 2PC (XA standard)

When to Use 3PC:

• Network is reliable, but node crashes are common
• Blocking is absolutely unacceptable
• Slightly higher latency is acceptable
• Network partitions are rare or can be detected and handled specially
• Custom implementation is feasible