I do not have a solution at present, but I'm wondering what happens if you commit the exchange (than the message is deleted from the queue and the database is updated) and than your route fails? Also as far as I know, the default transaction timeout for SPTM is 120 seconds. May be your 30 seconds are ok for one transaction?
Best, Christian On Wed, Jan 9, 2013 at 6:51 PM, erstanl <erst...@gmail.com> wrote: > Willem, thanks for the idea. Here is a resulting issue I have run into. The > 1st route takes a message from queue/batch/ready, it throws it into the > seda > queue. It basically takes every message it can and stuffs it into the seda > queue as fast as it can. The second route does process them as I would > expect, but I cannot allow the first route to consume more than one at a > time. There are many more machines running this same route that will not > have a chance to get any messages. > > <route> > <from uri="q:queue:queue/batch/ready" /> > <transacted/> > <to uri="bean:batchListener?method=init" /> > <to uri="seda:queue.process" /> > </route> > > <route> > <from uri="seda:queue.process" /> > <to uri="bean:batchProcessor?method=process" /> > </route> > > So I came up with this. It fulfills the ability to consume only as many as > needed to process, but I don't think its handling the transaction boundary > well because of the "blockWhenFull" attribute. It appears that the blocking > on the first route is holding the transaction open until it is able to > commit the message to the seda queue. > > <route> > <from uri="q:queue:queue/batch/ready" /> > <transacted/> > <to uri="bean:batchListener?method=init" /> > <to > > uri="seda:queue.process?size=2&blockWhenFull=true&concurrentConsumers=1" > /> > </route> > > <route> > <from > > uri="seda:queue.process?size=2&blockWhenFull=true&concurrentConsumers=1" > /> > <to uri="bean:batchProcessor?method=process" /> > </route> > > I understand that the seda component is asynchronous, and that we are > essentially using it to clip off the transaction at the route boundary. But > that has its obvious downside of draining the actvemq queue in rapid > fashion > and queuing them in seda. It is almost as if I need to us a vm component > instead of seda, but vm will participate in the transaction, which is the > original problem. I have looked into using a throttle on the first route, > but the data size being transferred is very inconsistent, and I cant rely > on > the throttle to feed the second route appropriately. > > I appreciate your help. If you could please let me know how I might be able > to use camel to achieve what I have mentioned above. > > > > -- > View this message in context: > http://camel.465427.n5.nabble.com/transactions-that-span-multiple-routes-tp5723735p5725194.html > Sent from the Camel - Users mailing list archive at Nabble.com. > --
