Stackbook Logo
data-consistencylegacy · high operational burden

Two-Phase Commit

Also known as: 2pc, xa-transactions

Intent

Commit a transaction atomically across multiple resource managers so all commit or all abort.

Problem

A single business operation updates several databases or services. If some commit and others fail, the system is left inconsistent. Local transactions cannot span independent participants.

Forces

  • •Atomicity across independent participants
  • •Coordinator crash can leave participants uncertain
  • •Locks held during the protocol reduce concurrency
  • •Network failures can delay decisions

Solution

Overview

Two-phase commit, or 2PC, is the classic atomic commit protocol. A coordinator drives all participants through prepare and commit so the outcome is the same everywhere. It is the basis of XA transactions and many distributed database internals such as cross-shard commits.

How it works

Phase 1 (prepare)
  Coord -> P1, P2: PREPARE
  Pi: write redo log + keep locks, reply YES or NO
Phase 2 (decision)
  all YES: Coord logs COMMIT, sends COMMIT, Pi commit + release
  any NO / timeout: Coord logs ABORT, sends ABORT

The coordinator must write its decision to durable storage before telling anyone. A participant that voted yes can no longer abort on its own; it is in doubt until it hears the outcome. On restart it asks the coordinator, or peers via the cooperative termination protocol, what happened.

Pitfalls

  • Blocking: if the coordinator dies after prepare, in-doubt participants keep row locks until it returns. Replicate the coordinator log with consensus to reduce this.
  • Latency grows with the slowest participant and with two sync disk writes plus network trips.
  • Lock contention limits throughput on hot rows.
  • Operators who force-commit stuck transactions risk inconsistency between participants.
  • Message brokers and HTTP services seldom support prepare, so 2PC rarely spans heterogeneous systems.

Key takeaways

  • 2PC gives atomicity but sacrifices availability on coordinator failure.
  • Use it for few, fast, trusted participants, ideally inside one database system.
  • For long or cross-service workflows prefer sagas or try-confirm-cancel.

✓ When to Use

  • •Few participants within one trust boundary needing strict atomicity
  • •Databases supporting XA or prepared transactions
  • •Short transactions with reliable low-latency networks

✗ When Not to Use

  • •Long-running business processes across services
  • •Participants across unreliable or public networks
  • •Systems that cannot tolerate blocking on coordinator failure

Pros

  • +True atomic commit across participants
  • +Well understood with standard support such as XA
  • +Simple application model

Cons

  • −Blocking if coordinator fails after prepare
  • −Holds locks across network round trips
  • −Reduces availability and throughput

Cost Profile

Infrastructure

Transaction coordinator and durable logs

Operational

High: in-doubt transaction recovery

Cognitive

Medium: protocol states

Failure Modes

  • Coordinator crash leaves in-doubt participants holding locks

  • Heuristic manual commit causes divergence

  • Participant timeout during prepare aborts a transaction that others may commit

Real-World Examples

Alternatives

  • saga-pattern

Related Patterns

  • distributed-transactions
  • saga-pattern
  • outbox-pattern

Competency Domains

data statereliability ops