On Thu, Feb 16, 2012 at 11:52 AM, Babak Vahdat <[email protected]> wrote: > 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 >
Yep the swiss quality is outstanding. It works every time, and is easy to use. I spoke to my colleague G.Nodet whom also has a Jura machine. > 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. -- Claus Ibsen ----------------- FuseSource Email: [email protected] Web: http://fusesource.com Twitter: davsclaus, fusenews Blog: http://davsclaus.blogspot.com/ Author of Camel in Action: http://www.manning.com/ibsen/
