Distributed Transaction Solutions: Theory, Patterns, and Practical Implementations

As business complexity grows, many systems evolve from monoliths to micro‑service architectures, inevitably encountering the challenge of distributed transactions. This article summarizes classic solutions and practical implementations.

Basic Theory

Before discussing specific solutions, the article reviews the ACID properties of database transactions and illustrates the need for atomicity in a simple money‑transfer example.

Distributed Transactions

It defines distributed transactions as operations spanning multiple nodes, explains why traditional ACID cannot guarantee consistency across services, and introduces the BASE principles that relax some constraints.

Solution: Two‑Phase Commit (XA)

XA, defined by the X/Open group, involves a transaction manager (TM) and resource managers (RM) and proceeds in a prepare phase followed by commit/rollback. The article notes that most major databases support XA.

Solution: SAGA

SAGA breaks a long transaction into a series of local short transactions coordinated by a saga orchestrator, using compensating actions when a step fails.

Solution: TCC (Try‑Confirm‑Cancel)

TCC separates the transaction into three phases—Try (resource reservation), Confirm (final execution), and Cancel (rollback). It emphasizes the need for idempotent implementations.

Solution: Local Message Table

Originally proposed by Dan Pritchett (eBay), this pattern stores pending messages in a local table to guarantee atomicity between business logic and message publishing.

Solution: Transactional Message

RocketMQ’s transactional messages replace the local message table, ensuring atomicity between message sending and local transaction execution.

Solution: Maximum‑Effort Notification

This approach repeatedly attempts to notify the receiver, with exponential back‑off and a fallback query interface for eventual consistency.

Solution: AT Mode

AT (Automatic Transaction) is an Alibaba/Seata mode similar to XA but without requiring explicit compensation code.

Network Anomalies in Distributed Transactions

The article categorizes anomalies such as empty rollback, idempotency violations, and hanging, illustrating each with TCC examples.

Sub‑Transaction Barrier Technique

DTM introduces a barrier that records sub‑transaction states in a table, preventing empty rollbacks, ensuring idempotency, and avoiding hanging. The core API is:

func ThroughBarrierCall(db *sql.DB, transInfo *TransInfo, busiCall BusiFunc)

This barrier can be applied to XA, SAGA, TCC, and transactional messages, simplifying error handling for developers.

Conclusion

The article provides a comprehensive overview of distributed transaction fundamentals, compares major patterns, and offers practical guidance for handling network failures and ensuring reliable transaction processing.