Distributed Transaction Fundamentals and Solutions: CAP, BASE, 2PC, TCC, Reliable Messaging, and Maximum‑Effort Notification

Distributed transactions are essential for modern micro‑service architectures where a single business operation spans multiple services or databases. The article begins by defining a transaction with a real‑world example, then explains local (database) transactions and the ACID properties (Atomicity, Consistency, Isolation, Durability).

It introduces distributed transactions, describing scenarios such as cross‑service order creation, multi‑database operations, and multiple services accessing the same database instance. The need for coordination across network boundaries is highlighted.

CAP Theory – Consistency, Availability, Partition tolerance – is explained with e‑commerce examples, and the three possible trade‑offs (AP, CP, CA) are discussed, emphasizing that a distributed system can satisfy at most two of the three properties simultaneously.

BASE Theory extends CAP by relaxing strong consistency in favor of Basic Availability, Soft state, and Eventual consistency, providing a foundation for “soft” transactions.

Two‑Phase Commit (2PC) is presented as the classic database‑level solution. The preparation and commit phases are illustrated with a simple code example:

begin transaction；
//1. local DB operation: debit A
//2. remote call: credit B
commit transaction;

The XA protocol and its limitations (need for XA‑compatible databases, long lock holding) are noted.

Seata offers an application‑level 2PC alternative. Its components – Transaction Coordinator (TC), Transaction Manager (TM), and Resource Manager (RM) – are described, and a flow diagram shows how a global transaction is created, branches are registered, and commit/rollback decisions are coordinated.

TCC (Try‑Confirm‑Cancel) is detailed with the three required operations per branch, handling of empty rollbacks, idempotency, and hanging problems. An example of a money transfer between accounts demonstrates the Try, Confirm, and Cancel methods.

Reliable Message (Eventual Consistency) Solution uses a local message table to achieve atomicity between the local DB operation and message sending, with a scheduled task that retries sending until the message broker acknowledges it.

RocketMQ Transactional Messages provide built‑in support for the atomicity problem. The required listener interface is shown:

public interface RocketMQLocalTransactionListener {
    RocketMQLocalTransactionState executeLocalTransaction(Message msg, Object arg);
    RocketMQLocalTransactionState checkLocalTransaction(Message msg);
}

And the producer setup:

TransactionMQProducer producer = new TransactionMQProducer("ProducerGroup");
producer.setNamesrvAddr("127.0.0.1:9876");
producer.start();
producer.setTransactionListener(transactionListener);
SendResult sendResult = producer.sendMessageInTransaction(msg, null);

Maximum‑Effort Notification is described as a lightweight approach where the notifier sends a message to a broker and relies on the consumer’s ACK mechanism to retry delivery, or the consumer can query the notifier for the final status if messages are lost.

A comparison table summarizes the trade‑offs among 2PC, TCC, reliable messaging, and maximum‑effort notification in terms of consistency, throughput, and implementation complexity.

The conclusion advises preferring single‑database local transactions when possible, carefully evaluating service granularity, and selecting the appropriate distributed‑transaction pattern based on the specific consistency, performance, and availability requirements of the application.