Appendix C: XA and Standalone Domains

The local transaction in chapter 12 covered one H2 resource. XA and domains address different questions: coordinating participating resource managers, and sharing global configurations between standalone applications. Neither belongs in the first rollback experiment.

Start this appendix after chapters 12, 18 and 19. You should be able to identify the transaction owner, explain a repeated request and distinguish outbox commit from publication. The following material is an advanced design/deployment workshop, not an additional guarantee of the local capstone.

Use ACB to inspect the boundary, not to invent support

Reopen checkpoint 12-transactions and inspect its Try scope and Database operations in ACB. That is the working local transaction boundary to compare with XA. Selecting a different transaction type cannot add participation to an ordinary HTTP endpoint.

The domain resource below is a separate configuration artifact, not an application flow. Open it in ACB’s text editor for review; this appendix does not claim a supported visual domain-authoring workflow or a completed domain project. Keep the domain deployment and XA resource-manager acceptance procedure separate from the local Run command.

XA coordinates participating resources, not arbitrary APIs

XA adds a transaction manager that coordinates multiple transactional resource managers through prepare and commit phases. A database and a compatible messaging resource can participate when their connector configurations, drivers and resource managers support that model. Setting transactionType="XA" is only the Mule-side declaration; it does not manufacture XA support in an ordinary endpoint. XA transactions.

An orders design that combines a database write with a supported transactional JMS send might justify that coordination. The deployment must also provide recoverable transaction-manager state and a procedure for interrupted commits. If a process or network link fails after prepare, operators need to determine and complete the recorded outcome — simply resending the business command can create a second problem.

No XA configuration or failure recovery was run for this edition. Before selecting it, verify the exact database driver, broker, connection configuration and deployment target together. Rehearse failures during both phases and measure lock duration and throughput under those failures. A successful happy-path commit says little about the recovery procedure that justifies the additional machinery.

The warehouse HTTP API does not become an XA participant because it shares a hostname with the database. If the warehouse reserves stock and the local insert later rolls back, the reservation remains unless the warehouse provides a separate cancellation or reconciliation operation. That is a business compensation with its own authorization, retry and audit requirements.

An outbox is often a useful alternative when the requirement is durable publication rather than synchronous cross-resource commit. Write the order and pending event in one local database transaction, then let a publisher deliver the event after commit. Delivery can repeat — the consumer still needs the stable business identity taught in chapter 18. This changes the timing contract deliberately: acceptance and fulfillment become distinct states.

Domains share resources across applications

A Mule domain lets associated applications on a standalone, on-premises runtime reference shared global configurations. For example, orders and returns applications can use one configured HTTP listener connection while owning different paths. A domain can also centralize connector configuration and its dependencies.

Domains do not contain shared flows, subflows or message processors. They provide resources, not a hidden application whose logic another app can invoke with flow-ref. An application belongs to one domain at a time. This is the standalone deployment model described by the domain documentation; it is not a CloudHub application deployment technique. Shared resources and domain limitations.

Here is a domain configuration for that shared listener:

Example 084 — Allocate a standalone shared listener

Source: workshops/domains/shared-listener.xml.

<domain:mule-domain
    xmlns:domain="http://www.mulesoft.org/schema/mule/ee/domain"
    xmlns:http="http://www.mulesoft.org/schema/mule/http"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xsi:schemaLocation="
      http://www.mulesoft.org/schema/mule/ee/domain
      http://www.mulesoft.org/schema/mule/ee/domain/current/mule-domain-ee.xsd
      http://www.mulesoft.org/schema/mule/http
      http://www.mulesoft.org/schema/mule/http/current/mule-http.xsd">
  <http:listener-config name="Shared_HTTP">
    <http:listener-connection host="0.0.0.0" port="8081"/>
  </http:listener-config>
</domain:mule-domain>

The domain project requires its own POM, descriptor and HTTP connector dependency. The resource configuration belongs in src/main/mule/mule-domain-config.xml. An associated orders application can reference Shared_HTTP in an ordinary http:listener, with a path such as /orders/*; the returns application can use /returns/*. Those paths are proposed allocations, not a tested pair of deployments.

The application’s POM declares its domain dependency with classifier mule-domain and scope provided. The deployed domain supplies that resource at runtime. For standalone deployment, domain archives belong under MULE_HOME/domains and applications under MULE_HOME/apps; the domain must be available before its dependent applications start. This ordering is a dependency, not a request to copy these teaching files into an active runtime.

Shared configuration creates shared consequences

Consistent resource configuration saves each application from duplicating it, but a change to the shared listener, connector version or credential can then affect several applications together. A domain release therefore needs a compatibility matrix covering its consumers — including applications whose teams requested no change.

Each application can pass its own tests while their combination overloads a shared resource or collides at startup. For orders and returns, assign ownership of listener paths, connection capacity, TLS configuration and secret rotation, and test the combined deployment as well as the applications independently.

Sharing a Database configuration through a domain does not make separate HTTP requests one transaction. Each event still has its own transaction boundary — sharing access to the resource is different from sharing an active unit of work. Nor does a domain create a business service contract between applications; use an explicit API or messaging interface where they exchange work.

When you migrate the orders application to CloudHub, inventory every domain reference before packaging. Move the required configuration into the supported application/deployment model and decide which shared resources should become external services. Replacing a domain dependency with copied XML may restore compilation while silently changing connection counts, credential ownership and operational coupling.

Define the acceptance environment before writing XA configuration

An XA trial needs the exact resource managers, XA-capable drivers, connector participation settings, transaction-manager persistence and recovery permissions. Record which resource owns each prepared branch and what an operator does after an interrupted commit. A generic two-resource diagram is not enough to supply a portable complete project.

For a domain trial, create a domain project with its POM and descriptor, then two dependent applications declaring the domain with provided scope. Deploy the domain first into an isolated standalone runtime, allocate distinct listener paths and verify both applications together. The shared-listener file above is the resource configuration only; it is not presented as a complete deployed project.

Test a connector-version change and credential rotation against both consumers. Shared configuration saves repetition by creating a shared dependency. A change to that dependency can affect a team that did not request a release.

Try it

1. Include a warehouse HTTP call. Does changing LOCAL to XA make its reservation roll back with the database?

Show answer

No. The endpoint must be an actual supported participating resource manager. An ordinary HTTP side effect needs its own compensation, idempotency or reconciliation contract.

2. Fail after prepare. What makes an XA recovery test different from resending the original command?

Show answer

The transaction manager and resource managers must resolve the recorded in-doubt branches. Resending can create a second operation while the first is unresolved. Test the exact recovery store and operator procedure.

3. Share a domain. Can two applications use Flow Reference to call logic placed in that domain?

Show answer

No. Domains share supported global resources, not flows or processors. Each application owns its executable logic and declares the domain dependency. Test shared resource capacity and compatibility together.

Not run. XA participants, prepare/commit interruption recovery, a custom Mule domain and its dependent applications were not deployed. The historical local rollback result remains evidence for one resource only.

Next: Appendix D: Synchronization and Platform Variants