Distributed Transactions in Enterprise Applications: From X/Open to MicroProfile LRA

Abstract

The problem of making several independent systems agree on a single outcome is older than most of the technology used to solve it. Historically, one of the
first protocol able to provide this synchronization was 2PC (two-phase commit)
that the application servers era made an ordinary feature of enterprise development.
Later lightweight frameworks, service-oriented and microservices architectures
have made the same guarantee considerably harder to obtain.

This article follows that problem from its formalization in the X/Open Distributed
Transaction Processing to the present situation. It then examines two working
implementations of an identical use case, one using XA and two-phase commit, the
other using the saga pattern, as specified by MicroProfile LRA, and compares them
on evidence rather than on preference. The accompanying source code is available
in the repository, where both implementations expose the
same REST contract and are exercised by the same test suite.

1. Origins: X/Open, and the Formalization of 2PC

The 2PC protocol is older than the standard that made it famous. Its
essential shape appears in the database literature of the late 1970s, notably in
the work of Jim Gray on the recovery and consistency properties of database
operating systems. The problem it addresses is easy to state and difficult to
solve: several parties must all either perform or decline an action. And they
must do that despite the possibility that any of them, including the party
conducting the negotiation, may fail at any moment.

As its name states, the protocol proceeds in two phases. In the first, the
coordinator asks every participant whether it is able to commit. A participant
that answers affirmatively cannot retract itself. It must have
written enough durable state to guarantee that it can still commit even after
a crash. In the second phase, the coordinator informs the participants of the
collective decision, which is affirmative only if every vote was affirmative.

In early '90s, the X/Open consortium decided to contribute by formalizing a reference
model named DTP (Distributed Transaction Processing). This model identified
three roles namely the application program, the transaction manager and the
resource manager. The following two interfaces have been defined:

• the TX (Transaction Demarcation) interface governs how an application demarcates a transaction;
• the XA (*eXtended Architecture) interface defines how the transaction manager drives the resource manager through the phases of the commit;

Once the XA specifications existed, a transaction manager written by one
vendor could coordinate a database written by another, and the industry acquired
a genuinely portable mechanism for distributed atomicity.

Let's note a property of the XA specifications that will become important
later. Between the moment a participant votes to commit and the moment it learns
the collective decision, it is blocked. It holds its locks, it cannot proceed,
and it cannot unilaterally decide. If the coordinator fails during this interval,
the participant waits. Skeen and others demonstrated in the early '80s that this
blocking behavior is not an artifact of a careless design but a logical consequence
of the quorum-based model which tolerates partitions only by blocking whenever no
quorum can be assembled. In 1985, Fischer, Lynch and Paterson published the article
Impossibility of Distributed Consensus with One Faulty Process which establishes
that deterministic consensus cannot be guaranteed in an asynchronous system in
which even one process may fail.

Because of this vulnerability 2PC was considered in the beginning a flawed protocol
that needed improvements. It took some time and experience to understand that,
on the opposite, it's an exact trade-off between perfect atomicity and availability.

2. Several Decades of Service

It would be reasonable to expect that a protocol with a documented blocking
failure mode and a known vulnerability would have been superseded. It has not
been. 2PC remains the most widely deployed mechanism for distributed atomicity
in enterprise systems, and it is likely to remain so for some time.

The explanation is that the failure mode is rare and the guarantee is absolute.
Within a single data center, coordinating two databases and a message broker
across a reliable local network, with a transaction manager whose recovery log is
on durable storage, the vulnerable interval is measured in milliseconds and the
recovery procedure is automatic. Financial institutions, telecommunications
operators and government systems adopted the protocol because the alternative was
to write compensation logic by hand for every business operation. Additionally,
software architects and developers are more confident in a protocol than in a
promise that reconciliation will probably catch any discrepancies.

Another important point to notice is that 2PC places complexity in the
infrastructure field, written once, by specialists, and consumed through a single
annotation. Every other alternative examined in this article moves that work into
application code, where it must be written again for each operation, by
developers whose principal expertise is the business domain rather than
distributed systems. This is a real cost and it is frequently underestimated.

3. OTS, JTS and JTA

The X/Open model assumed a particular shape: an application, a transaction
manager and some resource managers, generally within reach of one another. What
it did not address is the case that the OO (object-oriented) paradigm made
central the co,cept of transactions spanning objects that reside in different
processes, on different machines, supplied by different vendors, and invoked
remotely as though they were local.

The OMG (Object Management Group), the consortium behind CORBA, answered this in the
mid-1990s with the OTS (Object Transaction Service), adopted as one of the
CORBAservices. OTS described the roles of a distributed transaction in CORBA's
IDL (Interface Definition Language). The protocol underneath had not changed,
the same resources, participants and quorum, in Gray's sense, were at work and
no new algorithms has been proposed. OTS only specified how the 2PC participants
might be distributed objects. And it settled the question that X/Open had left
thin, namely how two transaction managers, from different vendors, should
interoperate.

OTS didn't displace XA but complemented it. The boundary to the resources, like
databases or message brokers, remained what it had been, OTS typically only fronted
resource managers driven over XA. Anything that OTS added sat above that
boundary, between the managers themselves.

The Jakarta EE platform, formerly Java EE and even formerly J2EE, absorbed this
model with considerable thoroughness. The JTA (Java Transaction API) specifications
defined the interface through which applications and application servers demarcate
transactions. JTS (Java Transaction Service) brought OTS into Java. It required
a transaction manager to implement that specification in its Java-mapped form,
to propagate transaction context between managers as OTS prescribed, and to
present JTA to the layer above. JTS was therefore not an alternative design but
OTS in Java, with a JTA façade.

The distinction between JTA and JTS is worth mentioning as the two are habitually
confused, usually as "JTA is the interface and JTS the implementation". That is
not quite it, since both are specifications. JTA is what an application programmer
sees: UserTransaction, TransactionManager, and the interfaces by which resources
are enlisted. JTS specifies what provides the guarantee underneath, including the
propagation of transaction context between processes and the interoperability of
transaction managers from different vendors.

For the application developer, the effect was remarkable and is easily forgotten
now. A method annotated for container-managed transactions would, upon invoking a
remote component, carry its transaction context to that component, enlist the
remote resources, and commit or roll back the entire assembly atomically. The
programmer wrote business logic. The container arranged consensus. This was one
of the genuinely impressive achievements of the enterprise Java period which
worked reliably across products from competing vendors and it is
somewhat unfair that it is now remembered as an old labyrinthine system.

4. CORBA and IIOP as the Transport of Context

The transaction context propagation just described required a mechanism, and the
mechanism was CORBA. Transaction context traveled between application servers
as part of the IIOP (Internet Inter-ORB Protocol), in the form of a service
context attached to the remote invocation. OTS defined how that context was
represented and how transaction managers should interoperate. IIOP carried it.

This arrangement was possible because the transport understood transactions.
A remote call was not merely a message but an invocation within a transactional
context, and the infrastructure at both ends recognized it as such. Enlistment
of the remote resource was automatic because the protocol carried the information
required to perform it.

The costs were substantial. CORBA was complex, its interoperability was achieved
by considerable effort and its programming model demanded interface definitions
and generated stubs. As the industry moved towards HTTP and simpler representations,
these costs became decisive. But it is important to record that the price of the
simplicity was HTTP lack of capacity to carry transactional semantics.

5. The Decline of Heavyweight Servers and the Rise of Lighter Frameworks

The reasons for the decline of the traditional application server are well
documented and only tangentially concerned with transactions. Deployment units
grew large and start-up times grew long at exactly the moment when elastic
infrastructure began to reward the opposite. Container images preferred a single
process to a shared runtime hosting many applications. The operational model of
the application server, in which several applications share a managed container
administered by a specialist team, was displaced by one in which each service
carries its own runtime and is administered by the team that wrote it.

Spring Boot, released in 2014, demonstrated that an embedded server and
convention-based configuration could deliver most of the productivity of the
enterprise stack with a fraction of its ceremony. Quarkus, which followed in 2019,
went further by moving substantial work from run time to build time, producing
start-up characteristics that make Java a plausible choice for serverless and
elastically scaled deployments.

Jakarta EE itself, transferred to the Eclipse Foundation in 2017 and subsequently
renamed, continues to evolve, and both Spring Boot and Quarkus rely on
substantial parts of its specifications. The change is therefore less a
repudiation of the enterprise Java model than a redistribution of it. The
specifications survived, the monolithic container that implemented them did not.

6. What the Lighter Frameworks Lost

Two changes occurred simultaneously. The first is architectural. The microservice
architecture style holds that each service should own its data, and that no other
service should reach into that data directly. This principle is incompatible with
2PC across services which requires the coordinator to be connected to
the resource managers. A coordinator that must not touch another service's
resources cannot enlist them.

The second is a matter of transport. HTTP does not propagate transaction context.
It doesn't provide an equivalent of the IIOP service context. A REST call is an
independent interaction whose relationship to the caller's transaction is not
represented anywhere, unless the application arranges to represent it.

The consequence, which is regularly misunderstood in practice, is that
annotating a method as transactional and then invoking a remote service from
within it produces no distributed transaction of any kind.
If the local transaction rolls back, the remote effect stands. If
the local transaction commits, nothing establishes that the remote one did, and
a remote call that returned no answer may have applied its change or may not,
leaving the caller no basis on which to decide. The divergence does not even
require the remote service to fail. The arrangement has the
appearance of a distributed transaction and none of the substance, which is the
least desirable of the available outcomes, since it fails while presenting the
appearance of success.

7. The Saga Pattern, and the Ease of Implementing It Incorrectly

The saga was described by Garcia-Molina and Salem in 1987, in a paper concerned
with long-lived transactions within a single database. Their observation was that
a transaction holding locks for a long period is destructive to concurrency, and
that certain long transactions may be decomposed into a sequence of shorter ones,
each of which commits independently, with a compensating transaction defined for
each step. If the sequence cannot be completed, the compensations for the
completed steps are executed in reverse order.

The saga doesn't provide isolation. This is not a defect of a particular
implementation but by definition. Intermediate states are visible to other
observers, because each step has genuinely committed. In exchange, no participant
holds a lock while waiting for a distant coordinator, and each service retains
authority over its own data.

The naive implementation, which is very common, executes each step and defines its
compensation as the arithmetic inverse. Let's consider the example of a money transfer
service, like the one presented in the associated project. A debit is compensated
by a credit of the same amount. This is wrong in two distinct ways.

The first defect is the visible intermediate state. Between the debit and its
compensation, the balance is genuinely reduced. Any concurrent observer, including
another saga evaluating whether sufficient funds exist, will read that reduced
value and may act upon information that is about to be invalidated.

The second defect is that the compensating action can itself fail. A credit is
an operation like any other, subject to validation, to constraints, and to the
account having been closed in the interval. A saga whose compensation fails is in
a worse condition than one that never began, since it has performed part of an
operation and it cannot undo it. The system requires human intervention, and the
humans require an explanation.

The remedy, illustrated in Section 10, is to arrange matters so that no
compensating write is required. If the first step reserves rather than acts, then
compensation releases the reservation, and a release cannot fail for business
reasons because it removes an obligation rather than creating one.

8. MicroProfile LRA

MicroProfile LRA, where LRA denotes Long Running Action, specifies a saga
coordination protocol for services communicating over HTTP. It is best understood
as an answer to the two negative effects identified in Section 6: it reintroduces a context
that travels with the call, and it reintroduces a coordinator that drives
participants to a common outcome. It does not, and cannot, reintroduce atomicity.

The programming model is declarative. A method annotated @LRA participates in a
long-running action, beginning one if required. Context propagates in the
Long-Running-Action HTTP header, which the implementation attaches to outgoing
calls and interprets on incoming ones. A participant declares its obligations
through further annotations:

• @Compensate, which is invoked if the action is cancelled;
• @Complete, invoked if it is closed successfully;
• @Status, by which the coordinator may enquire what a participant did;
• @Forget, by which a participant may discard state it no longer needs to retain.

Two properties of this protocol are commonly overlooked. The first is that participants
must be idempotent. The coordinator retries. A participant that applies its
effect a second time corrupts its own data. This is the requirement that appears
in every specification document and is absent from a remarkable proportion of
first implementations.

The second is that the coordinator is a separate process that calls the
participants back. As opposed to JTA where the transaction manager is embedded
in the application, under LRA it is not and the participant must reach the coordinator
to begin, join and end an action. The coordinator must reach every participant
to invoke its callbacks. It is entirely possible to construct a deployment in
which the first direction works as expected while the second does not, and the resulting
behavior is discussed in Section 10.

9. The XA Implementation in Detail

The use case is deliberately modest: transfer an amount from one account to
another and record the transfer. Two databases are involved, one holding accounts
and one holding the transfer log, because a single database would reduce the
problem to a local transaction and demonstrate nothing.

One component in this arrangement is essential: the Narayana transaction manager.
Its lineage is running back to the Arjuna research at the University of Newcastle
and provided two decades of good service as the transaction manager of JBoss and
WildFly. Its Quarkus extension, used here, brings a JTA implementation embedded
in the application's own process. It owns the object store, decides the outcome
and executes the 2PC protocol on the application's behalf. The same project supplies
the LRA coordinator that section 10 relies upon, so both implementations in this
article rely on the same body of code.

Configuration

Each datasource is declared as an XA one:

quarkus.datasource.accounts.jdbc.transactions=xa
quarkus.datasource.xfers.jdbc.transactions=xa

That flag is the entire mechanism. The connection pool supplies XAConnection
instances rather than ordinary ones, and each pool enlists an XAResource in the
active transaction upon first use.

The transactional method

@Transactional
public TransferDto processTransfer(TransferRequest request)
{
  Account source = accountRepository.getAccount(request.getSourceAccountId())
    .orElseThrow(() -> new AccountNotFoundException(request.getSourceAccountId()));
  Account destination = accountRepository.getAccount(request.getDestinationAccountId())
    .orElseThrow(() -> new AccountNotFoundException(request.getDestinationAccountId()));
  if (source.getBalance().compareTo(request.getAmount()) < 0)
    throw new InsufficientFundsException(source.getId());
  source.debit(request.getAmount());
  destination.credit(request.getAmount());
  Transfer transfer = new Transfer(Common.getRandomId(), source.getId(), destination.getId(),
        request.getAmount(), request.getCurrency(), TransferStatus.COMPLETED, LocalDateTime.now());
  transferRepository.createTransfer(transfer);
  return transfer.toDto();
}

There is no reference to two-phase commit in this code, and that is the
observation worth recording. The annotation causes a JTA transaction to begin. The
two repositories address two different datasources. Each datasource enlists itself.
When the method returns, Narayana performs the protocol.

The protocol as executed

Upon commit the transaction manager calls prepare on both branches. Each
PostgreSQL instance executes PREPARE TRANSACTION, writing the changes durably in
a state from which they can still either be commited or rolled back. If both
branches vote affirmatively, the transaction manager writes its decision to
its object store. This is the point at which the outcome becomes irrevocable
and then the transaction manager calls commit on both branches, each of which
executes COMMIT PREPARED.

Two consequences of operational importance follow. PostgreSQL refuses prepared
transactions unless max_prepared_transactions is configured with a positive
value, its default being zero, so an otherwise correct application fails at the
first commit. And the transaction manager's object store must be durable, since it
holds the only record of a decision made but not yet applied. Recovery must be
enabled so that transactions left in doubt by a failure are resolved when the
process returns.

The architectural cost

The transfer service interacts directly with the accounts database. It does not
ask anything of the account service, it holds the resource manager instead. This
means that it owns a connection to the accounts database and enlist it in its
own transaction. The transfer service opens that connection, modifies the account
rows itself through its own persistence layer, and the XAResource behind that
connection becomes a branch of the transaction that the transfer service began.
The account service plays no part. Its code does not run and it is not informed.
The commit decision belongs to the transfer service's transaction manager

This is not an oversight but a requirement. prepare and commit are operations
on an XAResource, and a service boundary exposes no equivalent of them. HTTP
offers no way to ask a remote service to make a change durable while leaving its
outcome open. A coordinator that cannot reach the resource manager cannot enlist
it. The consequence is that the two services need to share a database, and the
independence that the service boundary was intended to establish is not present.
The repository's docker-compose.yaml states this fact in one line: transfer is
given its own database, as well as the accounts datasource URL, whereas
transfer-lra is given, in addition to its own database URL, the one of the
account service.

10. The LRA Implementation in Detail

The saga implementation exposes an identical REST contract and reaches balances
only through the account service's HTTP interface. It has no dependency on the
accounts persistence layer, and that absence is the entire architectural point.

Reserve, then confirm

In the LRA implementation and as opposed to the 2PC one, the account service does
not move money when asked to reserve a debit. It records a Reservation in state
PENDING and leaves the balance unchanged. Available funds are computed as the
balance minus the sum of pending debits, so another possible concurrent saga
cannot reserve the same money. Upon @Complete the reservations are applied;
upon @Compensate they are released.

Accordingly, because the balance never moved, compensation performs no update
and, therefore, no persistence operation can fail during compensation. Hence,
the second issue identified in Section 7 is eliminated by construction rather
than by coding.

Idempotency, enforced twice

Reservations are identified, in business terms, by a triple consisting in the action identifier,
the account and the reservation type. Notice that the triple is not the entity's primary key,
which is a generated value, so nothing in the object model prevents a second row carrying the
same triple. And in order to avoid that, it is declared as a unique constraint in the database:

@Table(name = "RESERVATIONS",
  uniqueConstraints = @UniqueConstraint(name = "UK_RESERVATION_LRA",
    columnNames = {"LRA_ID", "ACCOUNT_ID", "RESERVATION_TYPE"}))

The constraint is needed because the account service, when asked to reserve a
debit, looks for an existing reservation before writing one, which is a
check-then-act sequence and, therefore, not atomic. Two deliveries of the same
reserve request can both find nothing and both insert. The constraint avoids that
and guarantees that the database refuses the 2nd reserve.

Retries could also cause the effect described above. The coordinator waits for
each callback, but a call that times out or whose reply is lost leaves the
action unresolved, so it keeps calling again and again. A settlement instruction
therefore might arrive more than once for a reservation that is already recorded. The
database constraint cannot help here, since no row is being inserted. Then the guard
sits one level down, in the service class shown below. As you can see, the two
callbacks annotated with @Compensate and @Complete annotations obtain their
reservations from a single helper, the pendingFor(...) method, that selects
only the PENDING reservations, so that the ones already confirmed or already
released are passed over rather than settled again.

@ApplicationScoped
public class AccountLraService
{
  ...
  @Transactional
  public ParticipantStatus complete(String lraId)
  {
    pendingFor(lraId).forEach(this::confirm);
    return ParticipantStatus.Completed;
  }
  ...
  @Transactional
  public ParticipantStatus compensate(String lraId)
  {
    pendingFor(lraId).forEach(reservation -> reservation.setState(ReservationState.RELEASED));
    return ParticipantStatus.Compensated;
  }
  ...
  private Stream<Reservation> pendingFor(String lraId)
  {
    return reservations.findByLra(lraId).stream()
     .filter(reservation -> reservation.getState() == ReservationState.PENDING);
  }
  ...
}  

11 The Project

The project that illustrates this article is a Quarkus workshop showing a simple
money transfer use case in the two ways that we discussed along the article:

• XA / 2PC (transfer, port 8080): a genuine 2PC across two XA datasources, coordinated by Narayana.
• Saga / MicroProfile LRA (transfer-lra, port 8090 and account, port 8081): a compensation-based consistency example across autonomous services, coordinated by a Narayana LRA coordinator.

Both expose the same /xfers REST contract and are driven by the same shared
test suite (transfer-tck), so any difference you observe is a difference in
transaction strategy and nothing else.

Modules

The following modules are part of the workshop project.

Each repository has two implementations: an in-memory one (DefaultAccountRepository,
DefaultTransferRepository) and a JPA/Panache one (AccountRepositoryXA,
TransferRepositoryXA). Both are @Alternative, so neither is enabled by default;
each application picks the XA pair explicitly through
quarkus.arc.selected-alternatives. Only the XA implementations participate in 2PC —
the in-memory ones are there to run the services without a database.

All four modules carry the Jandex plugin so their @Entity, @Provider and CDI bean
classes are indexed when consumed as external dependencies.

Endpoints

Three services expose an HTTP API, each with a Swagger UI at /q/swagger-ui. The
rows marked as callbacks are invoked by the LRA coordinator, not by clients.

Two things are worth reading off the table. The two transfer services present the
same POST /xfers contract, taking the same request body of
{sourceAccountId, destinationAccountId, amount, currency}, which is what allows
a single test class to exercise both. And the account service's participant API
sits under its own path prefix instead of altering the existing endpoints, which
is why the saga work left the original account tests untouched.

Build & test

Integration tests use Quarkus Dev Services (Testcontainers), so a running Docker
daemon is required. No manual database setup is needed. Each service seeds its own
data in dev/test profiles, on the behalf of the import.sql file for account and of the
import-accounts.sql for transfer. In the prod profile the account service
owns the accounts schema and no generation or seeding happens.

The following command runs the integration tests:

mvn clean verify

Here is the list of the integration tests provided with the project:

• AbstractMoneyTransferContractIT (transfer-tck): this is and abstract class serving as a superclass for all the integration tests. It defines the shared scenarios: happy path, insufficient funds, unknown account, listing and deletion. Assertions are on deltas*, and the balance/count probes are abstract, because the XA service can read the databases directly while the saga service can only get them by calling the API over HTTP. Failure paths assert the response body as well as the status. Both stacks must return the business error rather than transaction plumbing, which a status-only assertion would not catch.
• MoneyTransferIT (transfer): the contract against XA, with repository-based probes.
• MoneyTransferSagaIT (transfer-lra): the contract against LRA, with HTTP probes, plus saga-only assertions about the COMPENSATED audit row and released reservations.
• AccountResourceIT (account): account CRUD, debit/credit, 404 on unknown account, and rejection of overdrafts and invalid amounts.

Run the full stack

In order to run the full stack, production like, proceed as follows:

# Build the container images (container-image.build=true is enabled)
mvn clean package
docker compose up -d

docker-compose.yaml starts the whole comparison:

Both transfer services run against the same accounts, so you can drive the same
transfer through each and compare:

BODY='{"sourceAccountId":"ACC1","destinationAccountId":"ACC2","amount":10.00,"currency":"EUR"}'
curl -s -XPOST -H 'Content-Type: application/json' -d "$BODY" http://localhost:8080/xfers  # XA
curl -s -XPOST -H 'Content-Type: application/json' -d "$BODY" http://localhost:8090/xfers  # Saga
curl -s http://localhost:8081/lra/accounts/ACC1/availability                                # reservations

Note QUARKUS_LRA_BASE_URI on the two participants: it is the address the
coordinator uses to call them back, and without it a participant advertises a URL
that is only meaningful from its own side of the network.

A Swagger interface is also available with each API, as explained at §11 Endpoints.
Additionally, the smoke test script test-all.sh is a very convenient way to make
sure to cover all the test case possible combinations. here below is an example
of how to run it:

$ docker compose up -d
$ ./test-all.sh

=== Account API - http://localhost:8081/accounts ===
PASS POST /accounts (create ACC90, 1000.00) -> 201
PASS POST /accounts (create ACC91, 0.00) -> 201
PASS POST /accounts (create ACC92, 10.00) -> 201
PASS GET /accounts/ACC90 -> 200
PASS balance(ACC90) == 1000.00
PASS GET /accounts (list) -> 200
PASS PUT /accounts/ACC90 (rename owner) -> 200
PASS GET /accounts/ACC90 (confirm rename) -> 200
PASS customerName updated
PASS POST /accounts/ACC90/credit (50.00) -> 200
PASS balance(ACC90) == 1050.00
PASS POST /accounts/ACC90/debit (200.00) -> 200
PASS balance(ACC90) == 850.00

=== Account API - negative cases ===
PASS POST credit (-1.00) rejected -> 400
PASS POST debit (0.00) rejected -> 400
PASS POST debit (999999.00) insufficient funds -> 400
PASS GET /accounts/NOSUCH -> 404
PASS POST credit on unknown account -> 404
PASS POST credit without Content-Type -> 415
PASS balance(ACC90) == 850.00
PASS DELETE /accounts/ACC92 -> 204
PASS GET deleted account -> 404
PASS DELETE already-deleted account -> 404

=== Account LRA participant API - http://localhost:8081/lra/accounts ===
PASS GET /lra/accounts/ACC90/availability -> 200
PASS availability exposes balance/held/available
PASS POST /lra/accounts/ACC90/debit without LRA context -> 412
PASS POST /lra/accounts/ACC90/credit without LRA context -> 412
PASS balance(ACC90) == 850.00

=== XA Transfer API (2PC) - http://localhost:8080/xfers ===
PASS POST /xfers (ACC90 -> ACC91, 100.00) -> 200
PASS transferId returned: raizmjf
PASS balance(ACC90) == 750.00
PASS balance(ACC91) == 100.00
PASS GET /xfers/raizmjf -> 200
PASS GET /xfers (list) -> 200
PASS PUT /xfers/raizmjf (currency -> USD) -> 200

=== XA Transfer API - negative cases (nothing must move) ===
PASS POST /xfers insufficient funds -> 400
PASS POST /xfers negative amount -> 400
PASS POST /xfers unknown source -> 404
PASS POST /xfers unknown destination -> 404
PASS balance(ACC90) == 750.00
PASS balance(ACC91) == 100.00
PASS GET /xfers/NOSUCH -> 404
PASS DELETE /xfers/raizmjf -> 204
PASS GET deleted transfer -> 404

=== Saga Transfer API (LRA) - http://localhost:8090/xfers ===
PASS POST /xfers (ACC90 -> ACC91, 25.00) -> 200
PASS transferId returned: etmlebm
PASS balance(ACC90) == 725.00
PASS balance(ACC91) == 125.00
PASS GET /xfers/etmlebm -> 200
PASS GET /xfers (list, includes compensated) -> 200
PASS @Complete flipped the transfer to COMPLETED

=== Saga Transfer API - cancellation and compensation ===
PASS POST /xfers insufficient funds (saga cancels) -> 400
PASS balance(ACC90) == 725.00
PASS balance(ACC91) == 125.00
PASS @Compensate logged the cancelled transfer as COMPENSATED
PASS POST /xfers unknown destination (saga cancels) -> 404
PASS balance(ACC90) == 725.00
PASS GET availability after settled sagas -> 200
PASS held == 0 (no reservation left dangling)
PASS PUT /xfers/etmlebm (currency -> USD) -> 200
PASS GET /xfers/NOSUCH -> 404
PASS DELETE /xfers/etmlebm -> 204
PASS GET deleted transfer -> 404

=== Saga participant callbacks - @Status and @Forget (transfer-lra) ===
PASS coordinator started LRA: http://lra-coordinator:8080/lra-coordinator/0_ffffac120002_a03b_6ad35817_1ed
PASS POST /xfers with an externally started LRA -> 412
PASS GET /xfers/lra/status (@Status) -> 200
PASS @Status reports Compensated for the cancelled LRA
PASS balance(ACC90) moved by 0 (now 725.00)
PASS DELETE /xfers/lra/forget (@Forget) -> 200
PASS GET /xfers/lra/status after @Forget -> 404
PASS @Forget kept the transfer, only dropped its LRA id

=== Account LRA participant API - driving a saga by hand ===
PASS coordinator started LRA: http://lra-coordinator:8080/lra-coordinator/0_ffffac120002_a03b_6ad35817_1f2
PASS POST /lra/accounts/ACC90/debit (40.00, in LRA) -> 200
PASS balance(ACC90) moved by 0 (now 725.00)
PASS held(ACC90) moved by 40.00 (now 40.00)
PASS POST /lra/accounts/ACC91/credit (40.00, in LRA) -> 200
PASS balance(ACC91) moved by 0 (now 125.00)
PASS coordinator closed the LRA -> 200
PASS balance(ACC90) moved by -40.00 (now 685.00)
PASS balance(ACC91) moved by 40.00 (now 165.00)
PASS held(ACC90) moved by 0 (now 0)

=== Account LRA participant API - cancelling a saga by hand ===
PASS coordinator started LRA: http://lra-coordinator:8080/lra-coordinator/0_ffffac120002_a03b_6ad35817_1f7
PASS POST /lra/accounts/ACC90/debit (15.00, in LRA) -> 200
PASS held(ACC90) moved by 15.00 (now 15.00)
PASS coordinator cancelled the LRA -> 200
PASS balance(ACC90) moved by 0 (now 685.00)
PASS held(ACC90) moved by 0 (now 0)

=== Summary ===
87 passed, 0 failed

12. Comparison

The attached GitHub repository contains a multi-module Maven project with two
implementations. The
first uses JTA and XA to obtain a two-phase commit, and is contained entirely in
the transfer module. The second uses MicroProfile LRA, and is necessarily
spread across two modules: transfer-lra orchestrates the saga, while account
takes part in it. That difference in shape is not an accident of packaging. A
JTA coordinator that enlists resource managers directly can live in a single
module, the transfer one, whereas a saga cannot exist unless its participants
are reachable and callable, hence the necessity for it to live in two modules,
transfer-lra and account.

Both implementations satisfy the same test contract. The following differences
are therefore differences of mechanism and of consequence, not of capability.

Two entries deserve comment.

The row concerning failure is frequently presented as an advantage of 2PC on the
grounds that the rollbacks are clean. It may equally be regarded as a loss of
information. A canceled saga records that a transfer was attempted and
subsequently undone, which is an audit trail that a rollback cannot produce
because the rows were never committed. Whether this constitutes an advantage
depends entirely on whether the business is required to account for attempts as
well as for outcomes, and this is a question for the domain rather than for the
architecture.

The row concerning the location of difficulty is, in my opinion, the
one most often omitted from comparisons. 2PC is difficult once, in
infrastructure maintained by specialists. Sagas are difficult repeatedly, in
application code and this argument is important.

The correct conclusion is not that one approach supersedes the other. It is that
the choice is determined by whether the resource managers can be co-located under
a single coordinator. If they can, 2PC provides a stronger guarantee
for less application code. If they cannot, because the services are genuinely
independent or the resources do not support XA, then a saga is not the inferior
option but the only option, and the engineering effort should be directed at
implementing it correctly rather than at regretting the atomicity that was never
available.

13. The Present and the Future

Two-phase commit is not disappearing. It remains appropriate wherever resources
can be co-located, and a significant proportion of enterprise data continues to
reside in exactly such arrangements. Reports of its obsolescence generally
originate from contexts in which it was never applicable.

Sagas are becoming ordinary. What is changing is the level of abstraction at which
they are expressed. Handwritten orchestration is giving way to specified
protocols such as LRA, to workflow engines that record the state of long-running
processes durably, and to durable execution platforms in which the compensation
logic is expressed as ordinary code. The direction of travel is consistent: the difficulty is being moved
back out of application code and into infrastructure, which is where the industry
placed it in the first place, some thirty years ago, and where it appears to
belong.

An important development merit attention: the growing use of the outbox
pattern with event streaming, which achieves atomicity between a database change
and a message by writing both to the same database and publishing asynchronously.
This is neither 2PC nor a saga in the classical sense, and for many integration
problems it is a better answer than either. The second is the increasing
availability of formal verification tools for distributed protocols, which offers
some prospect that compensation logic might eventually be checked rather than
merely reviewed.

The underlying tension, however, is not a matter of technology and will not be
resolved by this development. Atomicity across independent parties
requires either that they transfer autonomy to a coordinator or that they accept
observable intermediate states. The FLP (Fisher, Lynch and Paterson) result and its relatives indicate that no
implementation will escape this choice. What improves is the quality of the tools
with which each side of the choice may be pursued, and the clarity with which the
choice is presented to the practitioners.

The most costly systems are not those that chose two-phase commit, nor those that
chose sagas, but those that believed they had chosen the former while in fact
operating the latter, without compensations.

References and Further Reading

• Gray, J. Notes on Data Base Operating Systems, 1978.
• Fischer, M., Lynch, N., Paterson, M. Impossibility of Distributed Consensus with One Faulty Process, Journal of the ACM, 1985.
• Garcia-Molina, H., Salem, K. Sagas, ACM SIGMOD, 1987.
• X/Open. Distributed Transaction Processing: The XA Specification.
• Object Management Group. Object Transaction Service.
• Eclipse MicroProfile. MicroProfile LRA Specification.
• The accompanying source code, quarkus-distributed-tx, containing both implementations, the shared contract test suite and a Docker Compose deployment that runs the two stacks side by side.