All participants voted yes; no participant can finish
Three databases in a hypothetical reservation system say they are ready to commit. The coordinator crashes before anyone learns the decision. Locked rows remain unavailable while customers wait.
Someone suggests rolling back any transaction older than a minute. Another participant might already have received COMMIT.
Ready is a durable promise to wait
Why cannot a prepared participant safely choose its own outcome after a timeout? What information would make the decision safe?
In two-phase commit, the coordinator asks participants to prepare. A yes vote means a participant has durably recorded enough to finish and retained the necessary resources. After collecting votes, the coordinator durably records the outcome before communicating it. Participants apply that outcome and eventually release their prepared state.
Synthesizing vector architecture diagram...
The decisive line is the durable decision, not the last network message. If the coordinator dies after sending only one commit, recovery must resend the same decision. If it dies earlier, protocol-specific recovery determines whether abort is established; absence of a record in an unavailable or stale log is not proof of abort.
Atomic commit does not invent isolation
Two-phase commit makes participants agree on commit versus abort. Their transaction isolation and locking still determine concurrent behavior. Weakly isolated local transactions can preserve atomicity while allowing a business anomaly. Choose the local and distributed concurrency protocol together.
Prepared work may hold row locks and other resources. Waiters can then consume connection pools and spread the outage. If a hot row remains locked for 100 ms per transaction in a serialized workload, that path cannot complete more than roughly ten such transactions/second. A global network round trip inside that lock window can be expensive.
Track prepared transaction age, coordinator decision availability, lock waits, and recovery backlog. Operators should use a documented recovery runbook, not manually roll back old records without proving their outcome.
Replicating the coordinator changes the failure window
A consensus-backed coordinator can recover a durable decision through surviving replicas. It reduces dependence on one process but still needs its quorum and functioning participants. It does not guarantee progress through every partition. āNon-blockingā claims require a precise failure model.
Use 2PC when participants implement compatible prepare/commit protocols and the invariant justifies holding resources across that boundary. A single database transaction may be simpler when co-location is feasible. A payment API or email provider usually does not expose a database prepare phase; you cannot enlist it by wrapping an HTTP request in BEGIN.
Mental model: prepare means āI can finish either way, and I will not choose alone.ā The durable coordinator decision resolves that obligation.
Transfer: the hotel and the email
A hotel database supports prepare, but the confirmation email service does not. Can 2PC guarantee a booking and exactly one email atomically?
Source trail: 10-two-phase-commit-and-saga-orchestration, 13-distributed-transactions-sagas-vs-two-phase-commit. See the source map for consolidation and reference-retained material.