Done.
On Mon, Sep 17, 2012 at 1:49 PM, Christian Müller <christian.muel...@gmail.com> wrote: > 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. >> > > > > --
