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 <[email protected]>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. >
