What Is a Distributed Transaction?

A distributed transaction is a single unit of work that spans two or more independent systems — separate databases, message queues, caches, or services — and requires all of them to commit together or roll back together. It extends the all-or-nothing guarantee of a local transaction across systems that each manage their own data and would otherwise succeed or fail on their own.

The difficulty is that there is no shared memory or common transaction log across the participants, and any of them — or the network between them — can fail midway. Without coordination, you get partial outcomes: an order saved in one database while the payment event never reaches the queue, or a cache updated while the system of record is not.

Approaches to Distributed Transactions

Several mechanisms exist, each trading consistency against availability and complexity.

• Two-phase commit (2PC). Two-phase commit is the classic protocol for strict atomicity: a coordinator asks every participant to prepare, then commits everyone only if all vote yes. In Java this is usually driven through the XA standard and a JTA transaction manager such as Narayana or Atomikos.
• Saga pattern. A long-running process is split into a sequence of local transactions, each with a compensating action that undoes it if a later step fails. Sagas favor availability and eventual consistency over strict, immediate atomicity.
• Outbox pattern. A service writes its data and an outgoing event in the same local transaction, and a separate process then delivers the event reliably — solving the dual-write problem without a global transaction.

2PC and XA give the strongest guarantee but are synchronous and blocking; sagas and the outbox pattern scale better and stay available under failure, at the cost of immediate consistency. The right choice depends on whether a brief inconsistency is acceptable for the operation at hand.

Distributed Transactions with Valkey and Redis

By default, Valkey and Redis are not participants in a distributed transaction. Their native transactions operate on a single node through MULTI/EXEC and have no way to coordinate with an external database or message broker.

Redisson, the Valkey and Redis Java client, changes that with its RXAResource implementation. It lets a Valkey or Redis operation enlist as a full participant in a JTA-managed distributed transaction, so a cache update can commit or roll back atomically alongside a relational database or a message queue. This capability is part of Redisson PRO.

For a hands-on guide with code, see How to Manage Transactions in Valkey and Redis on Java.