Red Hat Training

A Red Hat training course is available for Red Hat Fuse

Chapter 9. XA Transaction Demarcation


Red Hat JBoss Fuse supports a variety of different ways to demarcate XA transactions (that is, beginning, committing or rolling back transactions). You can choose the most convenient way to demarcate transactions, depending on the context.

9.1. Demarcation by Transactional Endpoints


In the context of a Apache Camel route, you have the option of enabling transaction demarcation in the consumer endpoint, which appears at the start of a route (that is, the endpoint appearing in from(...)). This has the advantage that the transaction scope spans the whole route, including the endpoint that starts the route. Not all endpoint types are transactional, however.

Auto-demarcation by JMS consumer endpoints

A Camel JMS consumer endpoint with XA transactions enabled will automatically demarcate a transaction as follows:
  1. The endpoint automatically starts a transaction (by invoking begin() on the XA transaction manager), before pulling a message off the specified JMS queue.
  2. The endpoint automatically commits the transaction (by invoking commit() on the XA transaction manager), after the exchange has reached the end of the route.
For example, given the XA-enabled component, jmstx (see Sample JMX XA Configuration), you can define a transactional route as follows:
// Java
import org.apache.camel.builder.RouteBuilder;

public class MyRouteBuilder extends RouteBuilder {
    public void configure() {

JMS producer endpoints

In contrast to consumer endpoints, JMS producer endpoints do not demarcate transactions (since producer endpoints typically appear at the end of a route, it would be too late to initiate a transaction anyway). Nonetheless, an XA-enabled producer endpoint is capable of participating in a transaction, if a transaction context is already present. In fact, it is essential to enable XA on a JMS producer endpoint, if you want it to participate in a transaction.

Transactional and non-transactional JMS endpoints

Because of the way that Apache ActiveMQ implements transactions, a transactional JMS endpoint must always be used in a transaction context and a non-transactional JMS endpoint must always be used outside of a transaction context. You cannot mix and match (for example, accessing a transactional JMS endpoint without any transaction context).
As a consequence of this restriction, it is typically convenient to define two different Camel JMS components, as follows:
  • A transactional Camel JMS component—to access JMS destinations transactionally.
  • A non-transactional Camel JMS component—to access JMS destinations without a transaction context.