anchor.diff:  
   [source,xml]
   ----
  -    <!-- setup JMS connection factory -->
  -    <bean id="poolConnectionFactory" class="org.apache.activemq.pool.PooledConnectionFactory" init-method="start" destroy-method="stop">
  -        <property name="maxConnections" value="8"/>
  -        <property name="connectionFactory" ref="jmsConnectionFactory"/>
  -    </bean>
  -
  -    <bean id="jmsConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
  -        <property name="brokerURL" value="vm://localhost?broker.persistent=false&amp;broker.useJmx=false"/>
  -    </bean>
  -
  -    <!-- setup spring jms TX manager -->
  -    <bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
  -        <property name="connectionFactory" ref="poolConnectionFactory"/>
  -    </bean>
  -
  -    <!-- define our activemq component -->
  -    <bean id="activemq" class="org.apache.activemq.camel.component.ActiveMQComponent">
  -        <property name="connectionFactory" ref="poolConnectionFactory"/>
  -        <!-- define the jms consumer/producer as transacted -->
  -        <property name="transacted" value="true"/>
  -        <!-- setup the transaction manager to use -->
  -        <!-- if not provided then Camel will automatic use a JmsTransactionManager, however if you
  -             for instance use a JTA transaction manager then you must configure it -->
  -        <property name="transactionManager" ref="jmsTransactionManager"/>
  -    </bean>
  +<!-- setup JMS connection factory -->
  +<bean id="poolConnectionFactory" class="org.apache.activemq.pool.PooledConnectionFactory" init-method="start" destroy-method="stop">
  +    <property name="maxConnections" value="8"/>
  +    <property name="connectionFactory" ref="jmsConnectionFactory"/>
  +</bean>
  +
  +<bean id="jmsConnectionFactory" class="org.apache.activemq.ActiveMQConnectionFactory">
  +    <property name="brokerURL" value="vm://localhost?broker.persistent=false&amp;broker.useJmx=false"/>
  +</bean>
  +
  +<!-- setup spring jms TX manager -->
  +<bean id="jmsTransactionManager" class="org.springframework.jms.connection.JmsTransactionManager">
  +    <property name="connectionFactory" ref="poolConnectionFactory"/>
  +</bean>
  +
  +<!-- define our activemq component -->
  +<bean id="activemq" class="org.apache.activemq.camel.component.ActiveMQComponent">
  +    <property name="connectionFactory" ref="poolConnectionFactory"/>
  +    <!-- define the jms consumer/producer as transacted -->
  +    <property name="transacted" value="true"/>
  +    <!-- setup the transaction manager to use -->
  +    <!-- if not provided then Camel will automatic use a JmsTransactionManager, however if you
  +         for instance use a JTA transaction manager then you must configure it -->
  +    <property name="transactionManager" ref="jmsTransactionManager"/>
  +</bean>
   ----
   
   And then we configure our routes. Notice that all we have to do is mark the
  -route as transacted using the *transacted* tag.
  -
  -[source,xml]
  -----
  -    <camelContext xmlns="http://camel.apache.org/schema/spring">
  -        <!-- disable JMX during testing -->
  -        <jmxAgent id="agent" disabled="true"/>
  -        <route>
  -            <!-- 1: from the jms queue -->
  -            <from uri="activemq:queue:okay"/>
  -            <!-- 2: mark this route as transacted -->
  -            <transacted/>
  -            <!-- 3: call our business logic that is myProcessor -->
  -            <process ref="myProcessor"/>
  -            <!-- 4: if success then send it to the mock -->
  -            <to uri="mock:result"/>
  -        </route>
  -    </camelContext>
  -
  -    <bean id="myProcessor" class="org.apache.camel.component.jms.tx.JMSTransactionalClientTest$MyProcessor"/>
  -----
  -
  -=== Transaction error handler
  -
  -When a route is marked as transacted using *transacted* Camel will
  -automatic use `TransactionErrorHandler` as the
  -xref:latest@manual:ROOT:error-handler.adoc[Error Handler]. This error handler supports basically the same
  -feature set as the xref:latest@manual:ROOT:defaulterrorhandler.adoc[DefaultErrorHandler],
  -so you can for instance use xref:latest@manual:ROOT:exception-clause.adoc[Exception Clause]
  -as well.
  -
  -[[TransactionalClient-IntegrationTestingwithSpring]]
  -== Integration Testing with Spring
  -
  -An Integration Test here means a test runner class annotated
  -`@RunWith(SpringJUnit4ClassRunner.class).`
  -
  -When following the Spring Transactions documentation it is tempting to
  -annotate your integration test with `@Transactional` then seed your
  -database before firing up the route to be tested and sending a message
  -in. This is incorrect as Spring will have an in-progress transaction,
  -and Camel will wait on this before proceeding, leading to the route
  -timing out.
  -
  -Instead, remove the `@Transactional` annotation from the test method and
  -seed the test data within a `TransactionTemplate` execution which will
  -ensure the data is committed to the database before Camel attempts to
  -pick up and use the transaction manager. A simple
  -example https://github.com/rajivj2/example2/blob/master/src/test/java/com/example/NotificationRouterIT.java[can
  -be found on GitHub].
  -
  -Spring's transactional model ensures each transaction is bound to one
  -thread. A Camel route may invoke additional threads which is where the
  -blockage may occur. This is not a fault of Camel but as the programmer
  -you must be aware of the consequences of beginning a transaction in a
  -test thread and expecting a separate thread created by your Camel route
  -to be participate, which it cannot. You can, in your test, mock the
  -parts that cause separate threads to avoid this issue.
  -
  -[[TransactionalClient-Usingmultiplerouteswithdifferentpropagationbehaviors]]
  -== Using multiple routes with different propagation behaviors
  -
  -*Since Camel 2.2*
  -
  -Suppose you want to route a message through two routes and by which the
  -2nd route should run in its own transaction. How do you do that? You use
  -propagation behaviors for that where you configure it as follows:
  -
  -* The first route use `PROPAGATION_REQUIRED`
  -* The second route use `PROPAGATION_REQUIRES_NEW`
  -
  -This is configured in the Spring XML file:
  -
  -[source,xml]
  -----
  -    <bean id="PROPAGATION_REQUIRED" class="org.apache.camel.spring.spi.SpringTransactionPolicy">
  -        <property name="transactionManager" ref="txManager"/>
  -        <property name="propagationBehaviorName" value="PROPAGATION_REQUIRED"/>
  -    </bean>
  -
  -    <bean id="PROPAGATION_REQUIRES_NEW" class="org.apache.camel.spring.spi.SpringTransactionPolicy">
  -        <property name="transactionManager" ref="txManager"/>
  -        <property name="propagationBehaviorName" value="PROPAGATION_REQUIRES_NEW"/>
  -    </bean>
  -----
  -
  -Then in the routes you use transacted DSL to indicate which of these two
  -propagations it uses.
  -
  -[source,java]
  -----
  -    from("direct:mixed")
  -    // using required
  -    .transacted("PROPAGATION_REQUIRED")
  -    // all these steps will be okay
  -    .setBody(constant("Tiger in Action")).bean("bookService")
  -    .setBody(constant("Elephant in Action")).bean("bookService")
  -    // continue on route 2
  -    .to("direct:mixed2");
  -
  -    from("direct:mixed2")
  -    // tell Camel that if this route fails then only rollback this last route
  -    // by using (rollback only *last*)
  -    .onException(Exception.class).markRollbackOnlyLast().end()
  -    // using a different propagation which is requires new
  -    .transacted("PROPAGATION_REQUIRES_NEW")
  -    // this step will be okay
  -    .setBody(constant("Lion in Action")).bean("bookService")
  -    // this step will fail with donkey
  -    .setBody(constant("Donkey in Action")).bean("bookService");
  -----
  -
  -Notice how we have configured the `onException` in the 2nd route to indicate in
  -case of any exceptions we should handle it and just rollback this
  -transaction. This is done using the `markRollbackOnlyLast` which tells
  -Camel to only do it for the current transaction and not globally.
  -
  +route as transacted using the `<transacted/>` XML tag.
  +
  +[source,xml]
  +----
  +<camelContext xmlns="http://camel.apache.org/schema/spring">
  +    <route>
  +        <!-- 1: from the jms queue -->
  +        <from uri="activemq:queue:okay"/>
  +        <!-- 2: mark this route as transacted -->
  +        <transacted/>
  +        <!-- 3: call our business logic that is myProcessor -->
  +        <process ref="myProcessor"/>
  +        <!-- 4: if success then send it to the mock -->
  +        <to uri="mock:result"/>
  +    </route>
  +</camelContext>
  +----
  +
  
positive.code:         </setBody>
          <bean ref="bookService"/>
      </route>
      </camelContext>
  ----
  
  That is all that is needed to configure a Camel route as being transacted.
  Just remember to use the *transacted* DSL. The rest is standard Spring
  XML to setup the transaction manager.
  
  [[TransactionalClient-JMSSample]]
  == JMS Sample
  
  In this sample we want to listen for messages on a queue and process the
  messages with our business logic java code and send them along. Since
  
negative.code: = Transactional Client
  
  Camel supports the
  http://www.enterpriseintegrationpatterns.com/TransactionalClient.html[Transactional
  Client] from the xref:enterprise-integration-patterns.adoc[EIP patterns]
  using JTA transactions.
  
  How can a client control its transactions with the messaging system?
  
  image::eip/TransactionalClientSolution.gif[image]
  
  Use a Transactional Client—make the client’s session with the messaging system transactional so that the client can specify transaction boundaries.
  
  Transactions are supported by Spring Transactions and also with a JTA Transaction Manager.
  
  Traditionally a JTA Transaction Manager are included in JEE application servers.
  However, when running microservice applications with Spring Boot, or Quarkus, then
  a 3rd-party JTA transaction manager can be embedded and used.
  
  In Camel transactions are supported by JMS messaging components:
  
  - xref:components::activemq-component.adoc[ActiveMQ]
  - xref:components::jms-component.adoc[JMS]
  - xref:components::sjms-component.adoc[Simple JMS]
  - xref:components::sjms2-component.adoc[Simple JMS 2.x]
  
  And all the SQL database components, such as:
  
  - xref:components::elsql-component.adoc[ElSQL]
  - xref:components::jdbc-component.adoc[JDBC]
  - xref:components::jpa-component.adoc[JPA]
  - xref:components::sql-component.adoc[SQL]
  - xref:components::mybatis-component.adoc[MyBatis]
  
  == Understanding Transactions
  
  A transaction is a series of events. The start of a transaction is often named begin, and
  the end is commit (or rollback if the transaction isn’t successfully completed).
  
  If you were to write in Java a locally managed transaction then it could be something like:
  
  [source,java]
  ----
  TransactionManager tm = ...
  Transaction tx = tm.getTransaction();
  try {
      tx.begin();
      // code here under transaction
      tx.commit();
  } catch (Exception e) {
      tx.rollback();
  }
  ----
  
  You start the transaction using the `begin` method. Then you have a series of events to
  do whatever work needs to be done. At the end, you either `commit` or `rollback` the
  transaction, depending on whether an exception is thrown.
  
  You may already be familiar with this principle, and transactions in Camel use the
  same principle at a higher level of abstraction. In Camel transactions, you don’t invoke
  begin and commit methods from Java code; you use declarative transactions, which can
  be configured using Java code or in XML files. Camel doesn't reinvent the wheel and
  implement a transaction manager, which is a complicated piece of technology to build.
  Instead, Camel uses APIs from either `camel-spring` or `camel-jta`.
  
  === Local vs Global Transactions
  
  TODO:
  
  === About Spring Transactions
  
  Camel uses Spring Transaction to manage transactions via its `TransactionManager`
  API. Depending on the kinds of resources that are taking part in the transaction,
  an appropriate implementation of the transaction manager must be chosen. Spring
  offers a number of transaction managers out of the box that work for various local
  transactions such as JMS and JDBC. But for global transactions, you must use a third-party
  JTA transaction manager implementation; JTA transaction manager is provided
  by Java EE application servers. Spring doesn't offer that out of the box, only the necessary
  API abstract that Camel uses.
  
  === About JTA Transactions
  
  TODO:
  
  == Using Transactions in Camel
  
  TODO:
  
  === Transaction error handler
  
  When a route is marked as transacted using ``<transacted/>` Camel will
  automatically use `TransactionErrorHandler` as the
  xref:latest@manual:ROOT:error-handler.adoc[Error Handler].
  
  This error handler supports basically the same
  feature set as the xref:latest@manual:ROOT:defaulterrorhandler.adoc[DefaultErrorHandler].
  
  === Transaction Policies
  
  Outbound endpoints will automatically enlist in the current transaction
  context. But what if you do not want your outbound endpoint to enlist in
  