Understanding Distributed Transaction Protocols: XA, 2PC, 3PC, TCC, Saga, and Reliable Message Consistency

XA / Two‑Phase Commit

The XA protocol coordinates a global transaction across multiple resource managers (databases) via a transaction manager. The manager asks each database to prepare; if all respond OK, the transaction is committed, otherwise it is rolled back. This approach works for monolithic applications but suffers from low efficiency and poor scalability under high concurrency.

JTA

JTA (Java Transaction API) is the Java specification for XA‑based transactions. The @Transactional annotation used in Spring is a JTA transaction manager. Spring can use application‑server‑provided JTA managers (e.g., JBoss) or third‑party libraries such as Atomikos or Bitronix, all of which are wrapped for easy use.

Chained Transaction Manager

Spring also offers a chained transaction manager that aggregates multiple data‑source transactions. It executes the transactions in reverse order on rollback, but if a later transaction fails it cannot roll back earlier committed ones.

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, the earlier commits cannot be rolled back

This chained approach is lighter than JTA but only suitable for single‑node scenarios.

Three‑Phase Commit (3PC)

3PC improves on 2PC by adding a timeout mechanism and an extra preparation phase to avoid blocking and inconsistency.

CanCommit

PreCommit

If all participants reply “Yes”, the coordinator sends a PreCommit request, participants execute the operation, record undo/redo logs, and acknowledge.

If any participant replies “No” or times out, the coordinator aborts the transaction by sending an Abort request to all participants.

DoCommit

The final commit phase proceeds after a successful pre‑commit.

Coordinator receives ACKs from all participants, then sends DoCommit messages.

Participants commit the transaction, release resources, and send ACK back.

When the coordinator receives all ACKs, the global transaction is complete.

If abort is required, the coordinator sends Abort, participants roll back using the undo information recorded earlier, and acknowledge.

TCC (Try‑Confirm‑Cancel)

TCC splits a business operation into three phases: Try (resource check and lock), Confirm (execute the actual operation), and Cancel (compensate/rollback if any step fails). It is rarely used because compensation code can become complex, but it is common in payment and financial systems where strict consistency is required.

Saga

Saga implements long‑running transactions by having each participant commit its local transaction and, on failure, execute compensating actions for previously successful steps. It is suitable for scenarios with long workflows, many services, or third‑party systems that cannot provide TCC interfaces.

Advantages

One‑phase local commit, no locks, high performance.

Participants can run asynchronously, achieving high throughput.

Compensating services are easy to understand because they are the inverse of the forward operation.

Disadvantages

Does not guarantee transaction isolation.

Reliable Message Final Consistency

This pattern uses a prepared message in a message queue (MQ). If the prepared message fails to send, the operation is cancelled. After a successful send, the local transaction runs; on success, a confirm message is sent to MQ, otherwise a rollback message is sent. The MQ periodically polls prepared messages to ensure that any missed confirm messages are retried or rolled back, achieving eventual consistency.

Order‑Processing Example

Order system sends an order message to MQ marked “pending confirmation”.

MQ persists the message as “awaiting send”.

Order system receives persistence result; on success it creates the order.

After order creation, the result (success/failure) is sent back to MQ.

MQ updates the message status: delete on failure, mark as “ready to send” on success and deliver to the payment system.

Payment system processes the payment and follows the same pattern for subsequent steps (stock, shipping, etc.).

Maximum‑Effort Notification Scheme

System A completes its local transaction and sends a message to MQ. A dedicated notification service consumes the message, records it, and calls System B. If System B fails, the service retries N times before giving up.

Summary

For the strongest consistency, TCC is preferred; for most practical cases, message‑based eventual consistency is widely adopted.

ACID

BASE Theory

BASE stands for Basically Available, Soft State, and Eventual Consistency. It sacrifices strict ACID guarantees to achieve high availability in large‑scale distributed systems.

Basic Availability: some functionality may be degraded during failures.

Soft State: intermediate states are allowed and do not affect overall system availability.

Eventual Consistency: data may be temporarily inconsistent but will become consistent eventually.