Which Distributed Transaction Model Wins? A Deep Dive into 2PC, TCC, and Message‑Based Consistency

1. Prelude to Distributed Transactions

Transaction: A transaction is a reliable unit of work composed of multiple operations, characterized by ACID (Atomicity, Consistency, Isolation, Durability).

Local transaction: Managed by a resource manager, supports strict ACID, is efficient, but cannot span multiple resources.

Global transaction: Managed by a global transaction manager (TM) that coordinates resources for atomic commit/rollback.

TX protocol: Interface between application/server and transaction manager.

XA protocol: Interface between global transaction manager and resource managers; defines two‑phase commit and is widely implemented by databases.

AP, RM, TM: Application program, Resource Manager, Transaction Manager.

Two‑phase commit: TM coordinates RMs, prepares then commits; costly and vulnerable to failures.

BASE theory: Basic Availability, Soft state, Eventual consistency – trade‑offs for availability and performance.

CAP theorem: In a distributed system you can only have two of Consistency, Availability, Partition tolerance.

2. Flexible Transaction Service Patterns

1) Queryable operation: globally unique identifier and timestamp.

2) Idempotent operation: repeated calls produce the same result.

3) TCC operation:

Try: Check business, reserve resources, achieve provisional isolation.

Confirm: Execute business using reserved resources; must be idempotent.

Cancel: Release resources; also idempotent.

4) Compensable operation (Do/Compensate): Do performs business, Compensate undoes it, both idempotent.

3. Reliable Message‑Based Final Consistency Solutions

3.1 Reliable‑message pattern: business service records a message before committing, confirms after commit, ensuring the message is sent only if the transaction succeeds.

3.2 TCC compensation pattern: a business activity manager coordinates TCC services, logs operations, and invokes Confirm or Cancel at commit or rollback.

3.3 Maximum‑effort notification: the active side sends a message marked “pending”; the middleware persists it, and the active side decides further actions based on the persistence result.

3.4 Conventional MQ flow cannot guarantee consistency; messages may be lost or duplicated.

3.5 Idempotent design is required for duplicate delivery.

3.6 Local message service: the active side stores the message locally and in a real‑time service; the passive side acknowledges, after which the active side deletes the message.

3.7 Independent message service: pre‑send stores the message, business executes, then the message is marked sendable; consumption acknowledges, and a recovery subsystem retries unconfirmed messages.

public void completeOrderService() {
    // process order
    order.process();
    // send accounting voucher message
    pipe.sendAccountingVouchetMessage();
}

public void completeOrderService() {
    // send accounting voucher message
    pipe.sendAccountingVouchetMessage();
    // process order
    order.process();
}

XA‑related interfaces (XAConnection, XAConnectionFactory, XAQueueConnection, etc.) provide distributed transaction support but introduce additional cost, persistence overhead, and conflict with the goals of flexible transactions.

Message service design diagrams are omitted for brevity.