Two-Phase Commit (2PC)

April 2026 · 16 min read

When a single database transaction spans multiple machines — an order service debiting inventory, a payment service charging a credit card, and a shipping service reserving a slot — you need all of them to commit or all of them to roll back. There is no acceptable middle ground where payment succeeds but inventory is not deducted. The Two-Phase Commit protocol (2PC) is the classic solution to this atomic commitment problem in distributed systems. It is battle-tested, formally proven correct, and powers everything from traditional XA transactions to Google Spanner. It is also slow, blocking, and fragile in the face of certain failures. This post gives you the complete picture.

The Distributed Transaction Problem

On a single machine, atomicity is straightforward: the database writes to a write-ahead log (WAL), and either all changes are flushed or the entire transaction is rolled back from the log. The ACID guarantees hold because a single process controls the outcome.

In a distributed system, no single node controls all the data. Each participant holds a shard of the state, runs on separate hardware, and can fail independently. The fundamental challenge is:

Requirements for a Solution

1. Agreement — All participants that reach a decision reach the same decision (commit or abort).
2. Validity — If all participants vote YES and no failure occurs, the decision is COMMIT. If any participant votes NO, the decision is ABORT.
3. Termination — Every non-failed participant eventually reaches a decision. (This is the one 2PC cannot fully guarantee — more on that later.)
4. Durability — Once a participant commits, the changes survive crashes.

Why Not Just "Send Commit to Everyone"?

Consider a naïve approach: the coordinator sends COMMIT to all participants simultaneously.

• Participant A commits successfully.
• Participant B detects a constraint violation and cannot commit.
• Participant C never receives the message (network partition).

Result: A committed, B aborted, C is in an unknown state. The transaction is neither atomic nor consistent. We need a voting phase before the decision phase, and that is exactly what 2PC provides.

The 2PC Protocol

The protocol has two roles: a Coordinator (also called the Transaction Manager, or TM) and multiple Participants (also called Resource Managers, or RMs). The protocol proceeds in two phases:

Phase 1: Prepare (Voting)

Phase 2: Commit / Abort (Decision)

Formal State Machines

Coordinator FSM:

Participant FSM:

Write-Ahead Logging

Both coordinator and participants use force-write WAL at critical points to survive crashes. The log entries enable recovery:

Failure Mode Analysis

2PC handles many failure scenarios correctly. The problems arise in one specific window. Let us enumerate every case.

Participant Crashes Before Voting

Participant Crashes After Voting YES

Coordinator Crashes Before Decision

Coordinator Crashes After Decision

Network Partition

Coordinator + Participant Crash Simultaneously

The Blocking Problem in Depth

To truly understand why 2PC blocks, consider the information asymmetry in the PREPARED state.

The Uncertainty Principle

When a participant is in the PREPARED state (voted YES, waiting for decision):

• It cannot commit unilaterally — another participant might have voted NO, requiring an abort.
• It cannot abort unilaterally — all participants might have voted YES, and the coordinator might have already committed. Aborting would violate the agreement property.
• It cannot release locks — releasing locks before knowing the outcome could allow other transactions to read uncommitted data.

This is the only state in 2PC where a participant is uncertain. In INIT, it can abort. After COMMITTED or ABORTED, it knows the outcome. But in PREPARED, it is completely dependent on external information — the coordinator's decision.

Cooperative Termination Protocol

A partial mitigation: when a participant times out waiting for the coordinator, it contacts the other participants:

If all reachable participants are in the PREPARED state, no progress can be made. This is the worst case: everyone voted YES, the coordinator crashed before logging its decision, and now every participant is holding locks, unable to do anything.

Real-World Impact

In production systems, the blocking problem manifests as:

• Lock contention: Prepared transactions hold row-level or table-level locks. Other transactions that need those rows are blocked, causing a cascading pile-up.
• Resource exhaustion: Each prepared transaction consumes memory (undo logs, lock tables, connection slots). Enough blocked transactions can exhaust the system.
• Timeout cascades: Upstream services waiting for the blocked transaction time out, trigger retries, and create more load.
• Manual intervention: Often, a DBA must manually resolve in-doubt transactions after a coordinator crash — a process called heuristic resolution that can violate atomicity.

Three-Phase Commit (3PC)

In 1983, Dale Skeen proposed a modification to 2PC that eliminates the blocking problem under certain failure models: the Three-Phase Commit protocol (3PC). The key insight is to add an extra phase that propagates the coordinator's decision to participants before asking them to commit.

The Three Phases

Phase 1: CanCommit (Voting) — Identical to 2PC's prepare phase. Coordinator sends CAN-COMMIT?, participants respond YES or NO.

Phase 2: PreCommit — If all participants voted YES, the coordinator sends PRE-COMMIT. Participants acknowledge receipt. This is the crucial addition: it acts as a buffer between voting and committing. All participants now know that every other participant voted YES.

Phase 3: DoCommit — The coordinator sends DO-COMMIT. Participants commit and ACK.

Why 3PC is Non-Blocking

The magic of the PRE-COMMIT phase: if the coordinator crashes after sending PRE-COMMIT to some participants but not others, a recovery coordinator can safely decide:

• If any participant received PRE-COMMIT, we know all voted YES → safe to commit.
• If no participant received PRE-COMMIT, we can safely abort.

There is no longer a state where participants are uncertain and cannot determine the outcome from each other. The PRE-COMMIT phase ensures that before any participant commits, all participants know the decision.

3PC Trade-Offs

Google Spanner & TrueTime

Google Spanner is arguably the most ambitious distributed database ever built, and it uses 2PC as its distributed transaction protocol. How does it deal with the blocking problem?

Architecture Overview

Spanner combines several innovations:

• Paxos groups: Each shard is replicated across 5 data centers using Paxos consensus. The Paxos leader for each shard acts as the 2PC participant. If a leader fails, Paxos elects a new one in seconds — so the "participant" is effectively always available.
• 2PC over Paxos: The coordinator itself is a Paxos group. If the coordinator leader fails, a new coordinator leader is elected. This eliminates the single coordinator as a point of failure.
• TrueTime API: GPS and atomic clocks in every data center provide a global time API with bounded uncertainty: TT.now() returns an interval [earliest, latest] where the true time is guaranteed to be within. Typical uncertainty is 1–7 ms.

External Consistency via TrueTime

Spanner uses TrueTime to assign globally meaningful timestamps to transactions:

1. After all participants vote YES (prepare), the coordinator picks a commit timestamp s ≥ TT.now().latest.
2. Before sending the commit, the coordinator waits until TT.now().earliest > s — the so-called commit-wait.
3. This guarantees that any transaction that starts after this one in real time will see a later timestamp, ensuring external consistency (equivalent to linearizability).

The commit-wait is typically 7–14 ms (twice the clock uncertainty), which adds latency but provides something no other large-scale system offers: externally consistent distributed transactions at global scale.

Spanner's Answer to Blocking

Spanner does not eliminate 2PC's blocking — it makes it extremely unlikely:

• Coordinator crash → Paxos elects a new coordinator in ~10 seconds.
• Participant crash → Paxos elects a new shard leader with the prepared state already replicated.
• The "vulnerability window" where blocking could occur is reduced to the few seconds of Paxos leader election, rather than the hours or days of a crashed machine being replaced.

Performance Analysis

2PC is not a fast protocol. Let us quantify exactly how slow it is and where the time goes.

Latency Breakdown

For a cross-data-center transaction with 50 ms RTT and 5 ms fsync:

• Network: 2 × 50 ms = 100 ms
• Disk (critical path): 2 × 5 ms (coordinator prepare + commit) = 10 ms
• Lock holding time: at least 110 ms (from prepare to commit acknowledgment)

Compare this to a local transaction that takes ~5 ms. The overhead is 20× or more.

Throughput Impact

The real cost is not just latency — it is the lock duration. For the entire 2 round trips + processing time, the participant holds exclusive locks on the affected rows. This means:

• Other transactions that need those rows are queued, reducing throughput.
• The longer the lock is held, the higher the probability of deadlocks with other distributed transactions.
• With N participants across data centers, the abort rate increases due to timeouts, further reducing effective throughput.

Common Optimizations

2PC vs Alternatives

2PC is one solution to distributed transactions. Here is how it compares to the major alternatives:

Detailed Comparison Table

* 3PC is non-blocking only with reliable failure detectors, which are impossible to build in asynchronous networks (FLP impossibility).

When to Use 2PC

Good Fit ✓

• Traditional RDBMS replication (XA transactions): Enterprise systems using Java EE / JTA with multiple database resources. The latency overhead is acceptable because the databases are on the same LAN.
• Cross-shard transactions (same data center): Systems like Spanner, CockroachDB, and YugabyteDB use 2PC for cross-shard writes within a tightly controlled infrastructure.
• Financial transfers between accounts in the same bank: When atomicity is legally required and all participants are controlled by the same organization.
• Schema migrations across shards: Coordinating DDL changes that must be atomic.
• Short-lived transactions with 2–3 participants: The fewer participants, the lower the probability of failure during the vulnerability window.

Bad Fit ✗

• Microservices across organizations: Different teams control different services. Holding locks across service boundaries is impractical — a slow downstream service blocks everyone.
• Long-running business processes: Booking a trip (flight + hotel + car) should not hold database locks for seconds or minutes. Use Sagas instead.
• High-throughput event processing: Systems processing millions of events per second cannot afford 2 round trips and lock holding for each event.
• Cross-region / high-latency networks: With 200 ms RTT, the lock holding time becomes 400+ ms — unacceptable for most workloads.
• Systems requiring high availability: 2PC's blocking nature means any participant or coordinator failure can halt progress. Use eventual consistency patterns.

Real-World Implementations

Summary & Key Takeaways