The blocking commit

Why can one coordinator crashing leave every other participant waiting indefinitely?

Two-phase commit is the classic way to make several databases agree on one outcome. A coordinator asks everyone "can you commit?", collects the votes, and then tells everyone the decision. It is simple enough to sketch on a napkin, and it is genuinely correct: no participant ever commits while another aborts.

So why do practitioners speak about it the way they speak about a loaded weapon? The usual answer is "it blocks", which is true but not yet an explanation. What is worth working out is where the waiting comes from — because it turns out not to be a slow network or a bad implementation, but a place in the protocol where a participant genuinely does not have enough information to act, no matter how long it thinks about it.

Trace a participant's own knowledge, step by step, and ask at each point: could it decide alone?

Before it votes, easily. It has promised nothing, so if everything goes silent it can abort, safe in the knowledge that nobody could have committed — a commit requires all votes and its own was never given. After it hears the decision, also easily: it knows the outcome and applies it.

Now the interval between. It has voted yes. What does a yes mean? It is not an opinion — it is a promise. It says: I have durably prepared this transaction, I will not fail to commit it, and I have surrendered my right to abort unilaterally. To keep that promise it must hold its locks, because releasing them would let another transaction see or overwrite rows it may still have to commit.

Ask now what this participant knows about the outcome. It knows its own vote. It does not know the others'. So the transaction might commit — if everyone else also voted yes — or abort, if any one of them voted no. Both futures are live, and nothing in local state distinguishes them.

Then the coordinator crashes.

Here is the uncomfortable part. Can the participant guess? Suppose it commits. If some other participant voted no, it has just violated atomicity in the worst way — a partial commit that no recovery can undo. Suppose instead it aborts. If everyone voted yes and the coordinator had already told a faster participant to commit, it has again produced a split outcome. Either guess can be wrong, and the participant cannot tell which. So it waits. Not out of politeness, and not for a timeout to expire — it waits because acting would be unsafe, and it is holding locks the whole time. That is what "blocking" means, and it is a property of the protocol, not of any implementation.

Can the participants help each other? Somewhat. The cooperative termination protocol lets a stuck participant ask its peers what they know. If any of them heard the decision, the answer propagates. But if every reachable participant is in the same uncertain prepared state, the group learns nothing and they wait together.

Notice what is really scarce here. It is not agreement — the votes were unanimous. It is the decision record: the one durable fact saying which way the transaction went. That record lived in exactly one place, and that place died. The flaw is structural: a protocol whose outcome is known by a single node inherits that node's availability.

Which points straight at the fix. Do not entrust the decision to one machine. Replicate it. Modern systems put the commit decision into a consensus log — Raft or Paxos across an odd number of nodes — so the decision survives any minority failure, and any participant can read it back from whoever is up. Two-phase commit as a data protocol is retained; the coordinator as a single point of knowledge is not.

And what of three-phase commit, offered by textbooks as the non-blocking alternative? It does remove blocking, but only under an assumption we do not have: that failures are crashes rather than partitions, and that message delays are bounded. Under a partition it can produce inconsistency, which is worse than waiting. No commit protocol can be both non-blocking and safe against arbitrary partitions, so the honest framing is that you choose which failure you prefer, not that you escape both.

Three refinements.

First, the misconception worth correcting: blocking is often read as slowness, as though a longer timeout or a faster network would fix it. It is not a latency problem. A prepared participant that guesses is unsafe at any speed, so the wait is doing real work — it is the protocol preferring unavailability over a possible split outcome.

Second, the cost is not the waiting itself but the locks held while waiting. A prepared transaction pins rows, and other transactions queue behind them. One coordinator outage can therefore stall traffic that has nothing to do with the stuck transaction, which is why the operational damage is usually far wider than the transaction's own footprint.

Third, "two-phase commit is bad" is too coarse. What is fragile is a single, unreplicated coordinator. Once the decision is stored in a replicated log the failure that causes indefinite blocking requires losing a majority, and the protocol becomes ordinary engineering rather than a liability.

• The cooperative termination protocol, and precisely when it rescues a stuck participant.
• How a consensus-backed coordinator changes the failure modes rather than removing them.
• Sagas, which give up atomicity entirely and compensate afterwards instead.

Every term the collection defines is gathered in the glossary.