Thanks all - this is essentially my issue, that there seem to be multiple different ways of achieving the same thing. I'm using the book as a base for all my learning, checking the website for any new stuff we get by using the later version of Camel. The original thinking with XA is it seems to be exactly what the book example is demonstrating in the section on XA. I'm guessing what Claus is saying is that in this case XA is overkill.
At the end of the day a decent test should prove both working. I've got a test that simulates the database breaking, but my issue is I can't seem to do consumer.receiveBodyNoWait to check the queue as it complains about me introducing a second consumer for the same route. I'll raise this as a separate point on the forums if it's not covered already. I notice in the chapter nine example tests that it's the DLQ that gets inspected not the original queue. To answer some of Babak's points: - I use Spring 3.1 and put the exclusion on the camel dependency. It all seems to work fine like this. Having said that we aren't using new features of Spring quite yet so if there's a reason to avoid using 3.1 then let us know. I've been using dependency:tree to make sure we have only a single version of the jars at the same level, but obviously with that level being 3.1 in this case. - Even though we do deploy to Jboss, we tend to do most most things within in the app rather than rely on the container. Again, I don't know if this is good or bad, it's just the way stuff seems to be done here. Presumably if we were going to rely on jboss doing the XA stuff we'd need to include these dependencies at test time for our integration tests. On 16 February 2012 08:55, Claus Ibsen-2 [via Camel] < [email protected]> wrote: > On Wed, Feb 15, 2012 at 11:46 PM, Mikeycmccarthy > <[hidden email] <http://user/SendEmail.jtp?type=node&node=5488917&i=0>> > 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: > http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487694.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > > > > -- > Claus Ibsen > ----------------- > FuseSource > Email: [hidden email]<http://user/SendEmail.jtp?type=node&node=5488917&i=1> > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ > > > ------------------------------ > If you reply to this email, your message will be added to the discussion > below: > > http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5488917.html > To unsubscribe from Correct situation to use XA, click > here<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=5487694&code=TWlrZXljbWNjYXJ0aHlAZ21haWwuY29tfDU0ODc2OTR8LTE5MTEzMDE4NTI=> > . > NAML<http://camel.465427.n5.nabble.com/template/NamlServlet.jtp?macro=macro_viewer&id=instant_html%21nabble%3Aemail.naml&base=nabble.naml.namespaces.BasicNamespace-nabble.view.web.template.NabbleNamespace-nabble.view.web.template.NodeNamespace&breadcrumbs=notify_subscribers%21nabble%3Aemail.naml-instant_emails%21nabble%3Aemail.naml-send_instant_email%21nabble%3Aemail.naml> > -- View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489016.html Sent from the Camel - Users mailing list archive at Nabble.com.
