Add an additional test where the SQLExceptions happens after the second update.
Best, Christian On Mon, Sep 17, 2012 at 4:29 AM, James Carman <ja...@carmanconsulting.com>wrote: > Something like this: > > > https://github.com/jwcarman/camel-in-transaction/blob/master/src/test/java/org/apache/cmueller/camel/samples/camelone/quasi/JmsAndJdbcQuasiTransactionSampleTest.java > > > > On Sun, Sep 16, 2012 at 12:53 PM, Raul Kripalani <r...@evosent.com> wrote: > > Hi James, > > > > By using singular transactions rather than distributed transactions (XA), > > each resource involved is responsible for managing its own transaction, > i.e. > > the JMS session and the JDBC DataSource will run separate transactions. > > > > Camel has a concept called "Unit of Work" that is used to synchronise > > transactions, or quasi-transactional behaviour, across several endpoints > in > > a route. An example of a "quasi-transactional" action is found in the > File > > consumer endpoint, where the file only will be moved to the "done" > directory > > if the route hasn't failed. Otherwise it will be moved to the "failed" > > directory. > > > > In the scenario that Christian proposes, the JMS consumer will begin a > > transaction and will wait till the Exchange is done. At that point, it > will > > decide whether to commit or rollback the transaction depending on if > there's > > an Exception set or not in the Exchange. This way, you don't get full XA > > behaviour, but you get something pretty close. There's still a risk of > JMS > > and JDBC becoming falling out of sync if Camel crashes after JDBC commits > > but before the JMS endpoint is notified of the DONE exchange and commits > the > > local transaction there. > > > > To use this approach, you want to set transacted=true at the JMS > consumer, > > so that the JMS endpoint will manage its transaction. > > > > On the other hand, XA is a different story. With XA, you don't want > Camel to > > manage the transaction (you set transacted=false on the endpoint), > because > > the XAResource will enlist itself in the transaction automatically. If > you > > set transacted=true with XA, you'll begin to see exceptions due to the > JMS > > XAResouce being enlisted twice. > > > > While I worked at FuseSource, Charles Moulliard and I created examples > > showing both: > > a) XA Transactions involving JMS and JDBC > > b) JMS + JDBC local transactions > > > > You can find the source code here: [1] and [2]. Here is a video with the > > demo: [3], and the full webinar is split in two parts: [4] and [5]. > > > > Hope that helps! > > Raúl. > > > > --- > > Raúl Kripalani > > Enterprise Architect, Program Manager, Open Source Integration specialist > > http://about.me/raulkripalani | http://www.linkedin.com/in/raulkripalani > > http://blog.raulkr.net | twitter: @raulvk > > > > [1] https://github.com/FuseByExample/camel-persistence-part1 > > [2] https://github.com/FuseByExample/camel-persistence-part2 > > [3] http://www.youtube.com/watch?v=Fj9ECUW9nxc > > [4] > > > http://fusesource.com/require_registration_for?url=http://streaming.progress.com/fusesource/102711_FUSE_part_1_CM/index.htm > > [5] > > > http://fusesource.com/require_registration_for?url=http://streaming.progress.com/fusesource/112211_FUSE_Part_2_CM/index.htm > > > > > > > > -- > > View this message in context: > http://camel.465427.n5.nabble.com/Distributed-transaction-in-camel-route-tp5719279p5719433.html > > Sent from the Camel - Users mailing list archive at Nabble.com. > --
