Hi > 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.
Thanks God every body in the forum can freely express his own opinion, I did that as well as Claus where both were personal opinions. As I used to have exactly the same situation as you I though I could give back some lessons learned. In my case (JBoss (5.1)) it was IBM WebSphere MQ (camel-jms) and DB2 z/OS (camel-jpa) both of which are XA-complaint. However as Claus already said the setup of XA is not that easy. So consult your vendor's documentation for a correct setup of your XA-Resources. > 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. Don't poll activley from the JMS queue by yourself but just let camel-jms do it for you inside the DSL: from(jms: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. I hope at least at this point Claus does agree with me ;-) IMHO you should NOT do that. Camel 2.9.0 has been intensively tested with Spring 3.0.7 and who would guarantee you that Spring 3.1 is 100% binary backward compatible (not even Jürgen Höller :-)). Maven is all about TRANSITIV dependency management, so better rely on the version Maven recommends you. Probably in some corner cases (negative-testing) you would trigger some logic both in Camel and/or Spring where it's not part of your everyday App-Flow and suddenly BOOM! "NoClassDefFoundError", "NoSuchMethodError", "LinkageError" etc. > - 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. No, XA-TM of JBoss (Arjuna) is sitting there but you can NOT rely on him to the the Job for you as somebody has to TALK to him. You have (at least) two options for this: - Either talk to him DIRECTLY (through JNDI) using the plain JTA UserTransaction API, begin() commit() rollback() etc. However it's NOT trivial at all to code a correct transaction-demarcation along your 2 XA-Resources. - Delegate this hard job to Spring JtaTransactionManager! Last but not least you've got two feedbacks in this free-mind-space-forum, think about them carefully and make you own way... Good luck! Babak -- View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489302.html Sent from the Camel - Users mailing list archive at Nabble.com.
