When Two‑Phase Commit Fails: Exploring XA, 3PC, TCC and Reliable Messaging

XA Two‑Phase Commit

The XA protocol uses a transaction manager that asks each participating database to prepare . If every participant replies OK, the manager issues a commit ; otherwise it triggers a rollback . This works for single‑application scenarios that span multiple databases but suffers from low throughput and is unsuitable for high‑concurrency workloads.

JTA (Java Transaction API)

JTA is the Java specification that implements XA semantics and underlies the @Transactional annotation. Common JTA transaction managers include those provided by application servers (e.g., JBoss) and standalone libraries such as Atomikos and Bitronix, all of which are wrapped by Spring for out‑of‑the‑box use.

ChainedTransactionManager

Spring also offers a ChainedTransactionManager that aggregates multiple data‑source transactions. Transactions are committed in reverse order; if a later commit fails, earlier commits cannot be rolled back.

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 previous commit cannot be rolled back

Why XA Is Rarely Used

In microservice architectures each service should own its own database. Direct cross‑service database access violates this principle, so services communicate via APIs, eliminating the need for distributed XA transactions.

Problems with Two‑Phase Commit

Synchronization blocking : All participants hold locks until the final decision, causing resource contention.

Single point of failure : The transaction manager is a centralized bottleneck; its crash stalls the entire system.

Data inconsistency : Network failures during the commit phase can leave some participants committed while others remain uncommitted.

Three‑Phase Commit (3PC)

3PC improves on 2PC by adding a timeout mechanism and a dedicated prepare phase, splitting the commit stage into three steps: CanCommit , PreCommit , and DoCommit .

CanCommit

The coordinator asks participants whether they can commit. Participants respond with “Yes” or “No”.

PreCommit

Coordinator sends a PreCommit request.

Participants execute the transaction locally, logging undo/redo information.

Participants acknowledge with ACK.

If any participant replies “No” or times out, the coordinator aborts the transaction.

DoCommit

Coordinator sends DoCommit to all participants that ACKed.

Participants permanently commit and release locks.

Participants send a final ACK to the coordinator.

TCC (Try‑Confirm‑Cancel)

TCC splits a business operation into three phases:

Try : Check resources and lock or reserve them.

Confirm : Perform the actual operation.

Cancel : If any service fails, execute compensating actions to roll back.

Pros and Cons of TCC

Pros: No locks during the Try phase, high performance, participants can run asynchronously, compensation logic is straightforward.

Cons: Does not guarantee transaction isolation; compensation code must be written manually.

Reliable Message + Eventual Consistency

This pattern achieves distributed consistency using a message queue:

Process Steps

System A sends a prepared message to the MQ. If sending fails, the operation is aborted.

After a successful send, A executes its local transaction. On success it sends a confirm message; on failure it sends a rollback message.

System B receives the confirm message and runs its local transaction.

The MQ periodically polls prepared messages that have not received a confirm, allowing the consumer to check the local transaction status and decide whether to retry or roll back.

If B’s transaction fails, the system retries automatically; after exhausting retries, manual compensation may be required.

Order‑Processing Example

The order service publishes a prepared message, creates the order locally, then sends a confirm message. The payment and inventory services receive the confirm, execute their local transactions, and acknowledge. If any step fails, the corresponding rollback or compensation logic is triggered, ensuring eventual consistency.

Maximum‑Effort Notification

A dedicated service consumes MQ messages, records them, and calls the downstream system. If the downstream call fails, the service retries a configurable number of times before giving up.

Summary

For the strictest consistency guarantees, TCC is preferred. Most systems, however, rely on message‑based eventual consistency patterns such as reliable messaging or 2PC/3PC.

ACID vs. BASE

Traditional distributed transaction protocols (2PC, 3PC) aim to satisfy ACID properties. Message‑driven eventual consistency follows the BASE model—providing basic availability, soft state, and eventual consistency—to achieve high availability in large‑scale systems.