camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Claus Ibsen <>
Subject Re: Correct situation to use XA
Date Thu, 16 Feb 2012 08:54:55 GMT
On Wed, Feb 15, 2012 at 11:46 PM, Mikeycmccarthy
<> wrote:
> Hi all, two weeks into using camel in earnest and loving it already :)
> One point of confusion though...I have a very simple route, message off of a
> queue and into a database (using a DAO type bean though in preference to the
> JDBC component). If the write to the db fails I want to take a few attempts
> to write again then eventually pop it back on the queue for later
> consumption.I am using spring 3.1 and camel 2.9.
> My question is, should I be using XA to do this? I have setup atomikos but
> am getting mixed advice from the manuals (maybe I am just reading it wrong).
> The camel book and the activemq page on XA on the site say I should really
> be using XA. The camel site page on using Spring for transaction management
> seems to suggest Spring will take care of the transactionality of the entire
> route.
> Is XA the correct option for what I am doing?

No. XA is complicated, overkill, and hard to setup, and leads to false
impressions, that a message can never be lost.
Its better to architect a system, to detect duplicate messages, and
allow messages to be replayed in case of failures.
XA is slow and not so many people use it. Also not all resources
participating in a XA works well together. You have to
test this throughly.
Disclaimer: This is my personal opinion.

In your case, if writing to the DB is the last "step" in the
processing of the message. Then a regular single resource transaction
from the JMS broker is often sufficient. If writing to the DB fails,
then an exception is thrown, and that exception can be conveyed back
to the JMS TX manager, which then issues a rollback. A rollback in JMS
broker in transacted mode, is in fact a non-ack. So for example if the
server crashes after the DB has thrown an exception, then the message
is still on the JMS queue, when the server restarts. The JMS broker in
transacted mode, is in fact, waiting for a commit (= ack) of the
message before its regarded as successfully consumed.

Chapter 9 in the Camel in Action has such an example.

> Many thanks
> --
> View this message in context:
> Sent from the Camel - Users mailing list archive at

Claus Ibsen
Twitter: davsclaus, fusenews
Author of Camel in Action:

View raw message