AI Glossary / Data engineering and architecture / Intermediate

Two-phase commit protocol

Definition

The two-phase commit protocol, or 2PC, coordinates an all-or-nothing decision for a transaction involving multiple transactional participants. A coordinator first asks participants to prepare, then communicates a final commit or abort decision. The protocol helps prevent one participant from committing a distributed transaction while another independently abandons its corresponding part, under the protocol's assumptions and recovery rules.

What it means

A local database transaction can update several records atomically within its own transaction system. A distributed transaction extends the coordination problem across participants, such as two databases that must make related changes.

The two phases are preparation and decision, not two separate business transactions. Preparation means a participant has reached a state in which it promises to follow the eventual outcome. It is not the same as already committing. Two-phase commit is also different from two-phase locking: commit coordinates transaction outcome, while locking governs concurrent access to data.

How it works

In the prepare phase, the coordinator asks participants whether they can commit their work. A participant that votes yes records enough durable state to honor the later decision and retains necessary resources. A participant that cannot prepare votes no.

The coordinator can decide to commit only when the required participants are prepared. It records the outcome durably and tells participants to apply it. If preparation fails, it chooses abort according to the protocol. Participants record and acknowledge the decision so recovery can complete consistently after interruptions.

A prepared participant cannot simply change its mind because a response is slow. If it cannot discover the outcome, ordinary 2PC can block while holding resources. PostgreSQL's prepared-transaction documentation makes this operational cost concrete: prepared transactions retain locks and must be resolved by an appropriate transaction manager.

Three practical examples

1. Coordinated databases: A business process updates related records in two supported transactional databases. The transaction manager coordinates their outcome rather than treating two independent commits as one atomic operation.

2. Distributed inventory records: Two transactional stores update complementary allocation information. Both must support the required protocol; an ordinary external API call does not become a participant merely because the application calls it during the workflow.

3. Recovery operations: Administrators investigate a prepared transaction after a communication failure. They use durable decision records and the transaction manager's recovery process rather than guessing the outcome from elapsed time.

Think of it this way

Think of two custodians agreeing to release matched packages only after a coordinator makes one shared decision. Each first confirms that its package is ready and reserved, then follows the coordinator's recorded instruction.

The analogy has limits. Computer systems need durable records, identifiers and recovery procedures because messages and machines can fail. Readiness is a promise with consequences, not a casual reservation that each custodian may independently cancel whenever communication becomes inconvenient.

Worked example

Suppose a fictional transaction T88 must change an allocation record in database A and a corresponding fulfillment record in database B. Both perform their local work without final commitment. The coordinator asks them to prepare; A and B durably record readiness and vote yes.

The coordinator then records COMMIT for T88. A receives the message and commits, but the message to B is delayed. B remains prepared and uncertain about the outcome. It must not decide to abort merely because a timer expires: the global commit decision already exists, and A has acted on it.

When communication recovers, the decision is delivered again and B completes the commit. Recovery must recognize T88 and handle repeated decision messages appropriately. If B had instead voted no before a commit decision existed, the coordinator would direct an abort. The example separates a failure to prepare from uncertainty after preparation.

Illustrative case study

Fictional case study: CommitMeadow integrates two internal databases through a transaction manager. Routine tests show matching records, so the team adds failure tests at the protocol boundaries. One test interrupts communication after both databases prepare but before one receives the final decision.

The affected transaction remains unresolved and holds resources that delay other work. The team confirms that recovery can obtain the durable decision and finish the transaction, then adds monitoring for old prepared transactions and rehearses the documented recovery procedure.

CommitMeadow also identifies an email notification outside the transactional participants. It moves notification handling into a separately designed post-commit workflow. The project learns that distributed atomic commitment has a defined participation boundary; it does not automatically roll back messages or other external effects.

Common misconceptions and mistakes

A common mistake is treating prepare as commit. Another is assuming that a timeout proves every participant aborted. Once prepared, a participant may be unable to decide safely without learning the global outcome.

Do not equate 2PC with two-phase locking or assume it alone supplies every isolation guarantee across the system. Commit coordination and concurrency behavior must work together. Also distinguish atomicity from instant simultaneous visibility to every possible observer: messages arrive at different times, and the system's isolation and recovery design determines what readers can observe during completion.

Business use

Two-phase commit can be appropriate when a business invariant requires atomic changes across resources that support coordinated transactions. The benefit is a shared outcome; the cost includes coordination, durable logging and possible blocking during failures.

Teams should confirm participant support, ownership of the transaction manager and a tested recovery path. Monitor unresolved transactions and resource pressure, and keep the transaction scope focused. When a workflow includes unsupported external actions, a different consistency design may be needed. Evaluate the complete business process rather than assuming a database protocol makes every step automatically reversible.

People also ask

Are prepared changes already committed?

No. Preparation records readiness to follow the later decision; final commitment is a separate step.

Can 2PC block after a failure?

Yes. A prepared participant may have to wait until it can learn the decision, while retaining resources.

Is two-phase commit the same as two-phase locking?

No. The former coordinates commit or abort; the latter controls when transactions acquire and release locks.

Check your understanding

One participant has committed after receiving a durable global decision, while another prepared participant times out. May the second safely abort just because of that timeout?

Answer: No. It must resolve the recorded transaction outcome. An independent abort could conflict with the existing commit decision.

Related terms

• Distributed transaction
• Atomicity (database systems)
• Two-phase locking
• atomicity
• transaction coordinator
• prepared transaction
• durable log
• recovery
• saga

Learn next

Draw the states of one coordinator and two participants. Interrupt communication before preparation, after preparation and after the commit decision, then identify what evidence permits safe recovery in each case.

More in Data engineering and architecture

• Tuple space - A tuple space is a shared coordination space in which concurrent processes exchange structured collections of values called tuples.
• Tuple Type - A tuple type describes the structure of a tuple or record: its component attributes or fields and their associated types.
• Tuple-versioning - Tuple-versioning retains multiple versions of a database row, or tuple, to represent changes over time.
• Type - token distinction - The type - token distinction separates a repeatable kind or pattern from a particular instance of it.
• Unavoidable Redundancy - Unavoidable redundancy is a descriptive term for repeated information that cannot simply be removed by a proposed normalization decomposition without losing...
• Uncertain database - An uncertain database represents information whose value, existence or interpretation is not fully settled.

Sources

PostgreSQL, PREPARE TRANSACTION: https://www.postgresql.org/docs/current/sql-prepare-transaction.html

Oracle Database, distributed transactions and two-phase commit: https://docs.oracle.com/en/database/oracle/oracle-database/21/admin/distributed-transactions-concepts.html

These product sources illustrate coordinated commitment and prepared-state recovery. T88 and CommitMeadow are fictional; exact logging, isolation, optimizations and recovery procedures depend on the implementation.

Previous: Two-pass verification Next: Two-phase locking