openskills.info
Course catalog
Course Preview

Distributed Transactions and Two-Phase Commit

Distributed transactions make one logical change across multiple independent data stores or services. Two-phase commit coordinates those participants so they all commit or all roll back, even though failures can interrupt the decision process.

itDatabases and data storage

Don't Panic — Distributed Transactions and Two-Phase Commit

A distributed transaction is for work that crosses independent resources when a half-finished result is unacceptable. Think of a debit in one database and a credit in another. Two ordinary commits can leave the money in a state that has developed opinions. The job is not to make messages arrive together. The job is to make every participant eventually follow one outcome: commit or rollback.

The reassuringly administrative two-phase commit, or 2PC, asks each participant for a durable promise. An application starts the work. A coordinator asks each resource manager whether its local branch can commit. A yes vote means more than “looks healthy”: the participant wrote enough recovery information to survive a crash and entered the prepared state.

Then comes the decision. One required no vote aborts the transaction. All yes votes permit the coordinator to record commit durably and tell everyone. Participants can hear that decision at different times. This is fine. Atomicity is agreement on one recorded result, not a tiny synchronized trumpet fanfare.

The surprise is that prepared is neither committed nor safely abortable. A prepared participant that loses contact with the coordinator can be in doubt. It keeps its promise, and often its locks, while recovery finds authoritative evidence. A timeout means “investigate,” not “pick whichever answer would make the dashboard calmer.” PostgreSQL, MySQL, and Oracle expose prepared or pending work because somebody must find the decision without inventing it.

2PC is not consensus. Atomic commitment needs every required yes vote. Consensus replicates a decision or log with quorum rules. Modern distributed databases often use both: consensus keeps each shard available across replica failures, while a commit protocol coordinates the shards touched by one transaction.

Use 2PC for short work with a hard all-or-nothing invariant and participants that can prepare and recover. For long business processes, user interaction, or workflows that can converge later, a saga, transactional outbox, or idempotent reconciliation changes the cost into a more manageable shape. Nothing magical occurred; the guarantee changed.

Read the intro for the protocol and failure boundaries. Use the slides for coordinator, participant, and consensus relationships. Keep the cheatsheet nearby for recovery surfaces and decision rules. The practice reference and exercise let you see a prepared transaction outlive its original session, which is less alarming when it happens on purpose.

Where this skill leads

Relevant careers

See how this topic contributes to broader role-level skill maps.

Sources