Understanding Distributed Transaction Protocols: XA, Two‑Phase Commit, LCN, and TCC

XA Protocol

The XA protocol defines the communication between a global transaction manager (TM) and multiple resource managers (RM). It provides a standardized interface for coordinating distributed transactions, allowing the TM to manage transactions that span databases, message queues, and other resources.

Two‑Phase Commit (2PC)

Two‑phase commit splits a distributed transaction into a voting phase and a commit phase . In the first phase, the coordinator asks all participants whether they can commit; if every participant replies positively, the coordinator proceeds to the second phase, sending a commit command to all participants. The article lists the detailed steps for both phases and the possible outcomes (all succeed, some fail, timeout).

LCN (Lock‑Confirm‑Notify)

LCN is a framework that acts as the coordinator (TxManager) without producing transaction data itself. It supports three transaction modes—LCN, TCC, and TXC—after version 5.0. The acronym stands for Lock , Confirm , and Notify . The core steps are:

Create a transaction group (obtain a GroupId from TxManager before business code runs).

Join the transaction group (participants report their transaction info to TxManager after execution).

Notify the transaction group (TxManager decides to commit or roll back based on the final status and informs all participants).

TCC (Try‑Confirm‑Cancel)

TCC separates a business operation into three stages: Try (resource reservation and preliminary checks), Confirm (final execution, idempotent), and Cancel (release reserved resources). Unlike 2PC, TCC does not rely on XA support from the resource manager; instead, the business logic itself implements the compensation steps.

Business Compensation Mechanism

When a distributed workflow cannot achieve strong ACID consistency, a compensation mechanism is required. The article uses a travel‑booking analogy to illustrate scenarios where some sub‑transactions succeed while others fail, requiring rollback or adjustment. Key design points include:

Clear definition of the desired final state and the fallback state.

Support for idempotent operations and retry mechanisms.

Centralized workflow control (e.g., a workflow engine) to monitor and manage state.

Ability to execute compensating actions that may not be strict inverses of the forward actions.

Short‑term resource reservation (e.g., inventory hold) to enable safe rollback.

Overall, the article provides a comprehensive overview of distributed transaction fundamentals, practical frameworks (LCN, TCC), and the importance of robust compensation strategies in microservice architectures.