Rigid Transactions: Two-Phase Commit (2PC) and Three-Phase Commit (3PC) Explained

When I was a DBA in my first year, I attended a database lecture that mentioned distributed transactions and the two‑phase commit protocol, which I found confusing at the time.

In the previous article on distributed transactions we covered the definition and classification of distributed transactions, distinguishing between rigid (strong consistency) and flexible solutions.

Rigid Transactions

Rigid transactions are implemented at the underlying service level, requiring no business‑logic changes, and provide strong consistency. Because they are synchronous and block resources, they are suitable only for short‑lived transactions. Typical rigid solutions are 2PC and 3PC (two‑phase and three‑phase commit).

XA Protocol

The XA protocol was proposed in 1994 by Tuxedo and submitted to the X/Open group. Major databases such as Oracle, MySQL and DB2 have added XA support.

XA defines a standard interface that connects Resource Managers (RM) with a Transaction Manager (TM) to coordinate distributed transactions. For completeness, the definitions are:

Resource Manager (RM): Manages system resources and serves as the gateway to transaction resources. A database itself is an RM, and each RM handles its local transaction.

Transaction Manager (TM): The core coordinator of a distributed transaction. It orchestrates all RMs to complete the transaction.

2PC and 3PC are derived from the XA specification.

2PC

2PC (Two‑Phase Commit) is a classic, centralized protocol that guarantees atomicity. The coordinator in 2PC corresponds to the TM, while the participants correspond to the RMs.

The protocol consists of two phases:

Voting phase

Commit phase

First Phase (Three Steps)

TM initiates the transaction: the coordinator sends a request to all participants and waits for their responses.

RM executes the local transaction (but does not commit).

Each RM reports back to the TM: YES if the local work succeeded, NO otherwise.

After the first phase, two outcomes are possible:

A) At least one RM reports NO.

B) All RMs report YES.

Second Phase (Two Steps)

If outcome A occurs, the TM instructs all RMs to roll back.

TM sends a rollback command to every RM.

Each RM rolls back its local transaction.

If outcome B occurs, the TM instructs all RMs to commit.

TM sends a commit command to every RM.

Each RM commits its local transaction.

Regardless of rollback or commit, the transaction ends after the second phase.

Drawbacks of 2PC

Although 2PC provides atomicity, it suffers from several issues:

Synchronous blocking degrades performance because resources remain locked throughout both phases, making 2PC unsuitable for high‑concurrency scenarios. Solution: introduce timeout mechanisms.

The coordinator is a single point of failure; if it crashes before sending the commit command, all participants remain blocked. Solution: implement HA election for the TM and use checkpoints for recovery.

Data inconsistency can arise if the coordinator crashes after sending the commit command and some participants fail to receive it. Solution: add retry logic and inter‑participant communication.

Transaction progress can be lost when both the TM and an RM crash after the second phase begins, leaving the system unable to determine the final state.

3PC

3PC (Three‑Phase Commit) extends 2PC to mitigate its blocking problems. It introduces an additional pre‑commit phase and a non‑blocking can‑commit phase, reducing the impact of coordinator failures.

CanCommit Phase

TM sends a CanCommit request to each RM.

Each RM replies YES if it can potentially commit, otherwise NO; no resources are locked at this stage.

PreCommit Phase

If all RMs responded YES, the TM sends a PreCommit request. Each RM executes the transaction, records undo/redo logs, locks resources, and replies with ACK.

If any RM replies NO or times out, the TM aborts the transaction.

DoCommit Phase

When all RMs have ACKed the PreCommit phase, the TM sends a DoCommit request, and each RM finalizes the commit and releases resources.

If any RM fails to ACK within the timeout, the TM aborts; participants roll back using the previously recorded undo information.

Compared with 2PC, 3PC improves on the following points:

Timeout mechanisms are added for both TM and RMs, reducing blocking time.

The CanCommit phase does not hold resources, so a TM crash has limited impact.

When the TM recovers, it queries participants for their progress (Commit, PreCommit, or Rollback) to avoid lost transaction state.

2PC && 3PC Summary

Both 2PC and 3PC are widely used in databases, but they are not silver bullets and are unsuitable for high‑concurrency workloads.

Neither protocol can completely solve the consistency challenges of distributed systems; data inconsistency risks remain.

As Mike Burrows, author of Google Chubby, famously said, "there is only one consensus protocol, and that’s Paxos" – implying that ultimately Paxos‑based solutions are needed for true distributed consistency.