If you have a copy of Camel in Action, then read chapter 9, its all about transactions.
XA is much more complex and often slower. And the fact there is few XA TX managers out there. And how well are they really? And the idea of not ever loosing a message and that 2+ different IT systems can 100% be in consistent state, is IMHO a nirvana. Often its better avoiding XA and rely on the fact if you could write the to JDBC database (eg no exception was thrown) and it was the last step in the route, then you can also commit the JMS TX. As you already was reading from the JMS to start the route. Anyway in theory you need XA. But I would avoid using it at all cost. Or use it seldom. If you build systems where you can reply messages then its often easier and a better design. You would then need to use some duplication detection or have JDBC operations that has no side effect if the same message is replayed. On Sun, Jun 2, 2013 at 5:42 PM, Darwish <othman.darw...@progressoft.com> wrote: > Thanks Claus .. that's clear for me ..one more question please ... can i use > org.springframework.orm.jpa.JpaTransactionManager as transaction manager > instead of jms transaction manager ... my case is > > from AcitveMQ:myqueue > transacted =true > to myCustomCamelComponent > > my myCustomCamelComponent is acts as gateway to external system which > interact with database (read/write) .. i think i need to XA transaction > ..can you recommend a provider ? > > > > > > > > > > ----- > Othman Darwish > ProgressSoft Corp. > > -- > View this message in context: > http://camel.465427.n5.nabble.com/Transactions-and-Cache-Levels-tp5733618p5733625.html > Sent from the Camel - Users mailing list archive at Nabble.com. -- Claus Ibsen ----------------- www.camelone.org: The open source integration conference. Red Hat, Inc. FuseSource is now part of Red Hat Email: cib...@redhat.com Web: http://fusesource.com Twitter: davsclaus Blog: http://davsclaus.com Author of Camel in Action: http://www.manning.com/ibsen
