Three-Phase Commit (3PC)

How to avoid 2PC blocking when the coordinator fails — sacrificing partition tolerance and adding one round-trip.

Problem

The major flaw of 2PC is the "prepared" state: if the coordinator dies after prepare and before commit, participants do not know whether commit or abort was decided and stay blocked (locks held). In 1981, Dale Skeen proved that no atomic commit protocol can be both non-blocking and partition-tolerant, but that non-blocking is achievable under a synchronous assumption (bounded timing and fail-stop). That is exactly the promise of 3PC.

Forces

• Extra cost: one more round-trip than 2PC (3 phases instead of 2).
• Synchronous assumption: 3PC assumes all network delays are bounded; otherwise it degenerates.
• Partition vulnerability: split-brain possible if a partition isolates the coordinator and the quorum elects a new one.
• Election: requires an underlying election protocol (Bully, Raft) to pick the new coordinator.
• Implementation complexity: very few commercial RDBMS actually implement it.

Solution

3PC inserts an intermediate pre-commit phase between prepare and commit. Phase 1 (canCommit): the coordinator asks whether each participant can commit; each answers yes/no. Phase 2 (preCommit): if all said yes, the coordinator sends preCommit; each participant writes pre-committed in its log and answers ACK. Phase 3 (doCommit): the coordinator sends doCommit; each participant performs the local commit and releases. The key trick: a participant in pre-committed state knows all others voted yes; on coordinator crash, an election protocol picks a new coordinator that can safely conclude with doCommit, since abort is already excluded.

Structure

Coordinator                       Participants
    │                                  │
    │ Phase 1: canCommit? ──────────►  │
    │ ◄────────── yes/no ──────────────│
    │                                  │
    │ Phase 2: preCommit ───────────►  │  [write pre-committed]
    │ ◄──────────── ACK ────────────── │
    │                                  │
    │ Phase 3: doCommit ────────────►  │  [commit local]
    │ ◄──────────── ACK ────────────── │

If coordinator crashes between phase 2 and 3:
  Surviving participants run election (Bully / Raft)
  New coordinator queries each: "are you pre-committed?"
  If majority pre-committed → send doCommit
  Else → send abort
  → No participant remains blocked indefinitely (under synchronous assumption)

EDI implementation

3PC is primarily an academic object: Oracle, PostgreSQL, IBM DB2 implement 2PC but not 3PC. For an EDI hub, you do not deploy 3PC; you document its logic as a prerequisite for understanding why modern architectures migrated to sagas or consensus protocols (Raft, Paxos) that solve the problem differently. One indirect case: some distributed coordination platforms such as Apache ZooKeeper use a simplified variant (ZAB, ZooKeeper Atomic Broadcast) inspired by the same idea of avoiding blocked states. Understanding 3PC helps grasp the CAP trade-offs an EDI architect must make when their hub must coordinate multiple regions.

Anti-patterns

• Implementing 3PC yourself instead of adopting a modern protocol (Raft, Paxos) — complexity is huge and use cases are rare.
• Believing 3PC is "2PC without drawbacks" — it introduces partition vulnerability, which is often worse.
• Ignoring the synchrony assumption — on the Internet, delay bounds are not guaranteed and 3PC may decide wrongly.
• Mixing 3PC and geo-distributed environment — inter-DC latency violates synchronous bounds.

Related patterns

• Two-Phase Commit (2PC) — the origin; 3PC tries to fix its blocking.
• Paxos — modern alternative to distributed consensus (Lamport 1989).
• Raft — understandable version of Paxos, widely adopted.
• Leader Election — prerequisite for the 3PC recovery phase.

Sources

• Skeen D. — Nonblocking Commit Protocols, ACM SIGMOD 1981. The foundational paper. dl.acm.org
• Skeen D., Stonebraker M. — A Formal Model of Crash Recovery in a Distributed System, IEEE TSE 1983.
• Tanenbaum A., van Steen M. — Distributed Systems: Principles and Paradigms, 3rd ed., 2017, ch. 8.5 ("Atomic commit protocols").
• Bernstein P., Newcomer E. — Principles of Transaction Processing, 2nd ed., Morgan Kaufmann, 2009.