Two-Phase Commit (2PC)

Why 2PC matters

• Distributed database transactions. A transaction that updates two shards (or two databases via XA) needs atomicity — either both updates land or neither. 2PC is the canonical mechanism. CockroachDB, YugabyteDB, TiDB, and Spanner all use a 2PC variant under the hood.
• Banking transfers. Move $100 from account A in bank A's database to account B in bank B's database. Without 2PC, a crash between the debit and the credit creates or destroys money. With 2PC, the prepared state holds locks until the coordinator decides.
• Message broker exactly-once. Kafka transactions, RabbitMQ XA, and JMS XA use 2PC to guarantee that a message produced and a database row updated commit together — no duplicate processing on crash.
• Atomic config rollouts. A configuration change that must apply to a fleet of servers in lockstep can use 2PC: prepare on all, commit on all. Useful when partial rollout would leave the system inconsistent.
• Two-database joins. Legacy enterprise apps with one database for orders and another for inventory rely on XA + 2PC to maintain referential integrity across both.
• Filesystem snapshots. Some clustered filesystems (GPFS, Lustre) use 2PC-like protocols to take a coherent snapshot across all storage nodes simultaneously.

The protocol step by step

Coordinator C, participants P1..Pn. T = transaction ID.

1. Begin. Each Pi has done its tentative work (writes are in its undo/redo log but not yet committed). C decides T should commit; sends prepare(T) to every Pi.
2. Vote. Each Pi: acquires locks; force-writes prepare record + undo/redo to its log; replies vote-yes(T). If anything fails, force-writes abort record and replies vote-no(T).
3. Decide. C waits for votes (with a timeout). If all yes, C force-writes commit(T) to its log and sends commit(T) to every Pi. Otherwise C writes abort(T) and sends abort(T).
4. Apply. Each Pi force-writes the commit/abort record, applies (or rolls back), releases locks, sends ack to C.
5. Forget. When C has all acks, it can forget T (garbage-collect its log entries).

Counts: 2 message rounds, ~3n one-way messages on the happy path, plus one forced log write per participant per phase (so 4 fsyncs per participant on the happy path: prepare-write, vote, commit-write, ack). For 5 participants on NVMe (50 µs fsync) the protocol's lower bound is ~250 µs plus network round trips. On geo-distributed deployments the network dominates: 100-150 ms per cross-region round trip × 2 rounds = 200-300 ms minimum.

Failure modes and recovery

• Participant crashes before vote. No state on disk. On recovery, it has no record of T; C will time out, abort the transaction, and re-send abort. Safe.
• Participant crashes after vote-yes, before commit. Prepared record is on disk, locks are conceptually held. On recovery, participant queries C for the outcome ("presumed-abort" optimization: if no record, assume abort; "presumed-commit" assumes commit). Locks held until decision arrives.
• Coordinator crashes before sending decision. The blocking case. Surviving participants in prepared state cannot proceed. They can run cooperative termination (ask peers if any has heard the decision) — works iff the answer happens to be on a live peer. Else they wait for C to recover.
• Coordinator crashes after sending some commits. On recovery, C reads its commit record from log and re-sends commit to any participant that has not yet acked.
• Network partition between participants and coordinator. Same as coordinator crash from the participants' viewpoint.

2PC vs Paxos / Raft

People conflate them. 2PC is an atomic-commit protocol — it guarantees agreement on a single decision (commit or abort) for one transaction, but the coordinator is a single point of failure. Paxos and Raft are consensus protocols — they guarantee agreement on a sequence of values across a quorum, tolerating up to f failures with 2f+1 nodes. They solve different problems: you can use Paxos to replicate the coordinator's state in a 2PC, getting fault-tolerant 2PC. That is exactly what Spanner, CockroachDB, and Calvin do. The 2PC structure stays; the coordinator's single-point-of-failure is removed.

Common misconceptions

• "2PC = ACID across services." It only gives atomicity (and via locks, isolation against other 2PC transactions). Durability is each participant's responsibility. Consistency is application-level.
• "Blocking is rare in practice." In a single datacenter, coordinator failure is rare. Across regions or with public-cloud network blips, it happens often enough that operators prefer Paxos-replicated coordinators or saga patterns.
• "More participants is fine." Probability of any participant failing scales with n; latency is bounded by the slowest participant; lock-hold time is at minimum 2 round trips. 2PC degrades quickly past 5–10 participants.
• "Saga is just 2PC done worse." They have different guarantees. Saga gives no isolation (intermediate states are visible) but full liveness; 2PC gives isolation but can block. The right choice depends on whether your business invariants tolerate intermediate states.
• "3PC is widely used." 3PC is a textbook protocol; production systems mostly skip it for Paxos-Commit because 3PC fails under partitions, while Paxos-Commit handles them.
• "Two-phase locking and 2PC are the same." 2PL is a per-participant concurrency control mechanism (acquire locks during growing phase, release in shrinking phase). 2PC is a multi-participant agreement protocol. They are often used together but distinct.

XA in 30 lines, conceptually

• Application calls tm.begin() to start a global transaction. TM allocates an XID.
• Application calls into RM1 (database) and RM2 (queue); each RM enlists in the global transaction (the JDBC/JMS driver does xa_start(XID)).
• Application does its writes. Each RM stages them locally with the global XID attached.
• Application calls tm.commit(). TM iterates: rm.xa_prepare(XID) for each RM. Each RM forces its prepare log entry, replies XA_OK or XA_RBROLLBACK.
• If all OK, TM forces its commit record, then iterates: rm.xa_commit(XID). If any prepare failed, xa_rollback(XID) on all RMs.
• If TM crashes mid-decision: on restart, it re-reads its log; for any in-doubt XID, it re-issues commit or rollback to RMs (the RMs replay their prepared state via xa_recover()).