In the previous sections, we discussed how the status of the data is permanently persisted at the end of an operation.

However, enterprise applications are composed of complex operations that often involve multiple and heterogeneous data sources, such as databases, message brokers, caches, and so on.

An application functionality must be implemented to ensure the logical consistency of the data; this means that the individual operations that compose it, while insisting on different data sources, must still act as a single unit. They must complete everything successfully, or none of them can affect the status of the data.

How can we achieve this behavior?

The answer is the Extended Architecture (XA) specification. It's the X/Open Common Applications Environment (CAE) standard specification that was developed to define a transaction that uses more than one backend data store. Its goal is to define the specifications to make the transaction manager coordinate all of the transactions associated with a single data source (application servers, databases, caches, and message queues) as a single, global XA transaction.

In an XA architecture, there are two main actors involved, as follows:

• The global transaction manager, who is responsible for coordinating the different transactions as a single unit
• The XA resource, which represents the data source target of the single transaction

In Java EE/Jakarta EE, the XA standard, related to the handling of the distributed transactions across multiple resources, is implemented by the javax.transaction.xa.XAResource interface. It defines how the resource manager and the transaction manager should communicate in a Distributed Transaction Processing (DTP) environment.

The distributed transaction, also known as XA Transaction, is an ACID transaction that is executed across of independent participants, who are connected to each other through a communication network.

In a global distributed transaction, each node has its own transaction manager that manages a local transaction—after completion, the transaction manager communicates with the transaction managers of the other participants to share the state of the transaction to decide the final outcome.

Usually, in an extended architecture, one transaction manager is elected as a global transaction coordinator—it administers the other participants in the distributed transaction and it can be one of the participating nodes, or an independent service.

By what rules does the global transaction manager use to decide the outcome of an XA transaction?

The decision strategy is known as the consensus protocol.