The multi-threading has a couple of aspects to it and I'm not sure of what your use case is exactly. Is it that the single set of 5 writes is so slow or is it that you have 10 sets of 5 writes and that is getting backed up? If it is the last case then you can use: http://camel.apache.org/load-balancer.html
If you look at the round robin you can see that if you had a case where you wanted a transaction and you wanted to blow the load out sideways, each of the separate routes could then have their own thread/transaction. If you look at the example below, you can see that the direct:start isn't going to get backed up usually. That should let you put the transactions on the individual routes (but I'd have to test it.) You could probably use a SEDA queue with a thread pool as well. Now if each message flowing through is 5 writes and the write has to happen in a given period of time this won't help. But at that point nothing will really. If it is simply that you want that to be transactional and be able to handle. And if you have to be ultraconservative about it the incoming route could be a persistent JMS queue backed by KahaDB (did we ever switch to LevelDB) and then the "to" in the round robin would drop it onto another persistent queue (or maybe a virtual topic but I don't know enough about its operation.) Anyway the round robing load balancer should give the best of both worlds, a way to spread the load out onto individual threads each with a transaction associated with it. Since you have tests already it should be fairly easy to wring this out. One other benefit of the round robin is you could even have multiple VMs or physical machines where the transactions are sent to. Depends on what you're after. <camelContext id="camel" xmlns="http://camel.apache.org/schema/spring";> <route> <from uri="direct:start"/> <loadBalance> <roundRobin/> <to uri="mock:x"/> <to uri="mock:y"/> <to uri="mock:z"/> </loadBalance> </route> </camelContext> On Sat, Sep 17, 2016 at 7:21 AM, sairam75 <[email protected]> wrote: > Thanks for the response Claus. > > Agreed that the transaction should be done in a single transaction. The > idea > behind having multicasting is, we provide services and time complexity is > one of our major concerns. Hence we have multiple threads for invoking > independent write/update calls. In this case, for transaction management we > would need to sacrifice the time and can make all the calls as sequential. > So there isn't a way to manage as a transaction though when there are > multiple threads. > > > > -- > View this message in context: http://camel.465427.n5.nabble. > com/Transaction-management-when-multicasting-within-a- > route-tp5787657p5787668.html > Sent from the Camel - Users mailing list archive at Nabble.com. >
