Glossary term

Two-Phase Commit

Engineering definition of two-phase commit covering prepare and commit phases, atomic decision, coordinator failure, blocking, latency and validation.

Branch: Computer Engineering
Glossary type: concept
Content: Glossary term
Updated: Jun 26, 2026
Revision: v1.0.0 · reviewed

Definition

concept

Two-phase commit is an atomic commit protocol in which a coordinator first asks participants to prepare, then issues a final commit or abort decision.

Two-phase commit appears in distributed databases, transaction managers, storage systems and tightly coupled service architectures when multiple participants must make one all-or-nothing decision. A useful design states the coordinator, participant set, durable prepare record, decision log, timeout behavior, lock-holding period, recovery rule, blocking risk, operational limits and validation evidence.

Two-phase commit is an atomic commit protocol in which a coordinator first asks participants to prepare, then issues a final commit or abort decision. Its purpose is to make several participants reach one all-or-nothing transaction outcome.

Two-phase commit is useful when the system needs atomic visibility across multiple durable resources. It is also expensive and operationally strict: participants may hold locks while waiting, the coordinator decision must be durable, and some failures leave participants in an in-doubt state until recovery completes.

Transaction Model

Let the distributed transaction be:

X

and let the participant set be:

P_1,P_2,\ldots,P_n

The atomicity requirement is that every participant eventually reaches the same final decision:

D_i=D_j

for all:

i,j

where:

D\in\{\text{commit},\text{abort}\}

Phase 1: Prepare

The coordinator sends a prepare request. Each participant decides whether it can commit locally. If it votes yes, it must force enough state to durable storage to commit later even after a crash:

log_i(prepared,X)

A yes vote is a promise. After a participant votes yes, it should not unilaterally abort unless the protocol and recovery rules explicitly allow it.

Phase 2: Decision

The coordinator commits only if every participant voted yes:

V_{yes}=n\Rightarrow D=\text{commit}

If any participant votes no, times out before prepare, or cannot guarantee durability, the coordinator decides abort:

V_{yes}<n\Rightarrow D=\text{abort}

The coordinator records the final decision before notifying participants:

log_c(D,X)

Participants then commit or abort their local work and release resources.

Blocking Behavior

Two-phase commit can block. If a participant has entered prepared state and then loses contact with the coordinator before receiving the final decision, it may not know whether the global decision was commit or abort.

The in-doubt condition is:

prepared_i(X)=1\quad\text{and}\quad D_i=\text{unknown}

During this period, the participant may need to retain locks, undo records, redo records or reserved resources. The practical risk is not only latency; it is operational stall and resource retention.

Latency Cost

A simplified latency screen is:

T_{2PC}=T_{prepare}+T_{log,p}+T_{decision}+T_{log,c}

where T_prepare and T_decision include network round trips and coordination overhead, while T_{log,p} and T_{log,c} represent durable logging on participants and coordinator.

For:

T_{prepare}=25\ \text{ms}

T_{log,p}=8\ \text{ms}

T_{decision}=30\ \text{ms}

and:

T_{log,c}=6\ \text{ms}

the screened commit latency is:

T_{2PC}=25+8+30+6=69\ \text{ms}

before application processing and queueing delay.

Availability Screen

If the coordinator has availability:

A_c

and each required participant has availability:

A_i

a rough independent availability screen is:

A_{tx}=A_c\prod_{i=1}^{n}A_i

For one coordinator and four participants each at:

A=0.99

the transaction availability screen is:

A_{tx}=0.99^5=0.9510

This is only a first-pass screen. Correlated failures, network partitions, storage stalls and overload can dominate the result.

Lock Holding

Prepared participants often hold locks until the final decision is known. If local work time is:

T_w

and two-phase commit adds:

T_{2PC}

then minimum lock holding is approximately:

T_{hold}\geq T_w+T_{2PC}

If coordinator recovery takes:

T_{recover}

an in-doubt participant may hold resources for:

T_{hold}\approx T_w+T_{recover}

which can create lock contention, deadlock symptoms, queue growth and timeout cascades.

Boundary With Saga and Outbox

Two-phase commit tries to preserve one atomic transaction across participants. A saga commits local steps and uses compensating actions for later failure. A transactional outbox commits local state and event intent together, then publishes later.

The choice is not stylistic. Use two-phase commit only when participants can support durable prepare, blocking is acceptable, and atomic visibility is required. Prefer saga or outbox-style patterns when services own independent data, long-running locks are unacceptable, or compensation and eventual consistency are acceptable engineering tradeoffs.

Validation

Validation should include participant crash before prepare, participant crash after prepare, coordinator crash before decision, coordinator crash after decision log, delayed decision messages, duplicate decisions, lost acknowledgements, recovery from in-doubt state, timeout behavior, lock retention, partitioned coordinator, storage-log failure and operator recovery.

Useful evidence includes coordinator logs, participant prepare records, final decision replay, lock-hold distributions, in-doubt transaction count, recovery time, abort reason, timeout count, queue depth, downstream retry rate and proof that participants never split between commit and abort for the same transaction.

Failure Modes

Common failure modes include assuming a participant can prepare when it cannot durably recover, losing the coordinator decision log, timing out a prepared participant into a unilateral abort, holding locks across slow external calls, letting in-doubt transactions accumulate, retrying ambiguous commits without idempotency, treating 2PC as a general microservice pattern, and validating only the happy path where all participants answer immediately.

Two-phase commit is strongest when the participant set is small, tightly controlled and operationally prepared for blocking recovery. It is weakest when stretched across unreliable services, human-scale workflows, heterogeneous stores or networks where partitions and long pauses are normal.

REF

Disciplines