Understanding XA, 2PC, 3PC, JTA, TCC and Reliable Message Consistency in Distributed Transactions

XA / Two‑Phase Commit

The XA protocol defines a transaction manager that coordinates multiple resource managers; it asks each database to prepare, then commits if all respond OK or rolls back if any refuse, but suffers from blocking, single‑point‑of‑failure and potential data inconsistency.

JTA

JTA is the Java implementation of XA, providing the Java Transaction API and supporting annotations like @Transactional ; Spring can use JTA managers from application servers (JBoss) or libraries (Atomikos, Bitronix) out‑of‑the‑box.

Chained Transaction Manager

Spring’s ChainedTransactionManager places multiple data‑source transactions in order, committing them sequentially; if a later commit fails, earlier commits cannot be rolled back, leading to partial persistence.

1. start message transaction
2. receive message
3. start database transaction
4. update database
5. commit database transaction
6. commit message transaction   ## if this step fails, previous commits cannot be rolled back

Three‑Phase Commit (3PC)

3PC improves on 2PC by adding a timeout mechanism and a pre‑commit (prepare) phase, splitting the commit stage into CanCommit, PreCommit and DoCommit to avoid blocking and reduce inconsistency.

TCC (Try‑Confirm‑Cancel)

TCC separates a distributed operation into three steps: Try (resource check and lock), Confirm (actual business execution) and Cancel (compensating rollback if any step fails); it is rarely used because compensation code can become complex, but it is favored for high‑value financial transactions where strict consistency is required.

Reliable Message + Final Consistency

The workflow sends a “prepared” message to MQ, executes the local transaction, then sends a confirm or rollback message; the consumer (system B) processes the confirm, while MQ periodically polls unconfirmed messages to retry or roll back, ensuring eventual consistency even if the confirm message fails to deliver.

Maximum‑Effort Notification

System A sends a message to MQ after its local transaction; a dedicated notifier consumes the message, records it, and calls system B; if B fails, the notifier retries N times before giving up, providing a simple best‑effort delivery guarantee.

Summary

The strictest approach is TCC; most practical solutions rely on message‑based eventual consistency. ACID principles apply to 2PC/3PC, while BASE (Basically Available, Soft State, Eventual Consistency) underlies the message‑driven schemes, offering higher availability at the cost of temporary inconsistency.