Hi Yeah of course, like many other people around the world I was also one of the first readers of that "Kicks Ass" book back in December 2010 as I intended to setup my first App using Apache Camel with NO previous knowledege about it.
I'm deeply thankful to BOTH Claus & Jonathan who provided such a wonderful book. And if buying that book of mine could help Claus for just 0.1 cents to enjoy his (well known) swiss made coffee machine [1], well that makes me more than happy... @Claus I hope you enjoy that swiss made quality :-) [1] http://davsclaus.blogspot.com/2011/11/coffe-machine-and-camel-in-action.html Babak surya aditya wrote > > Babak, > > Thanks for such informative reply. Would like to add there is one full > chapter dedicated for handling transactions with camel in 'Camel in > Action' > book by Claus, et al. > > peace, > > On Wed, Feb 15, 2012 at 6:54 PM, Babak Vahdat > <babak.vahdat@>wrote: > >> Hi >> >> Given your use case using XA you're definetly on the right way! What you >> need is a *global* transaction and not a *local* one as you need the >> orchestration of the transaction boundries along the way through JMS >> together with your DB. >> >> If you would make use of local transaction managers, let's say spring >> JmsTransactionManager and DatasourceTransactionManager then you would >> already commit your jms message consumption through camel-jms before >> inserting the data into the DB. But then if you would violate some >> DB-Constraints while inserting the data then the message has been already >> consumed from the JMS point of view (alread commited). Making use of XA >> in >> this case has the advantage of not lossing any unsuccessfully processed >> message. So using XA you have a real "unit-of-work" while dealing with >> more >> than one single "resource". Following some notes: >> >> - You don't have to pop the message back on the queue for later >> consumption >> by yourself (as you said), as that's already given for free through the >> transaction (rollback of JMS message consumption). >> >> - If you run your App inside a JEE container then rely on its XA-TM, for >> example JBoss makes use of Arjuna. And then let Spring >> JtaTransactionManager >> talk to it. But if you run standalone then atomikos is a good choice. >> >> - Make sure your JMS provider has a meaningful setup for exhaustion of >> failed JMS messages otherwise you get the "poission message effect". For >> example Apache ActiveMQ exhausts after 6 retries after which it puts the >> unconsumed message into DLQ. >> >> - Don't use spring version 3.1 but the one Camel 2.9 relies on (3.0.7). >> if >> you make use of Maven for your build then you will get that dependency >> transitively for free if you would depend on camel-spring. Using "mvn >> dependency:tree" would show you already now that you've got a dependency >> conflict by your POM. >> >> Babak >> >> -- >> View this message in context: >> http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5487888.html >> Sent from the Camel - Users mailing list archive at Nabble.com. >> > -- View this message in context: http://camel.465427.n5.nabble.com/Correct-situation-to-use-XA-tp5487694p5489165.html Sent from the Camel - Users mailing list archive at Nabble.com.
