Skip to content
hashkey.bond

Archivedistributed-systems

Two-Phase Commit and Its Blocking Problem

2PC guarantees atomicity across databases and blocks forever if the coordinator dies at the wrong moment.

Published
Reading time
1 min read

Two-phase commit coordinates a transaction across participants: a prepare phase where each votes and locks resources, then a commit or abort decision.

The flow

  1. Coordinator sends prepare; each participant writes a prepared record durably and votes yes/no.
  2. If all vote yes, the coordinator logs the decision and sends commit; otherwise abort.
  3. Participants apply and release locks.

The blocking failure

If a participant votes yes and the coordinator crashes before broadcasting the decision, the participant holds locks and cannot decide alone. It must wait — possibly indefinitely. This is not a theoretical edge case in wide-area systems.

Mitigations

  • Presumed abort: participants may abort if they cannot reach the coordinator, at the cost of violating atomicity.
  • Three-phase commit: adds a pre-commit phase to reduce blocking, but assumes bounded delays and is rarely used.
  • Avoid distributed transactions: sagas with compensations, or design so one database owns the invariant.

Takeaway: 2PC is correct under crash-recovery assumptions and operationally fragile. Use it inside one trust domain with fast, reliable coordinators — not across services you do not control.