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:

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="";>
    <from uri="direct:start"/>
        <to uri="mock:x"/>
        <to uri="mock:y"/>
        <to uri="mock:z"/>

On Sat, Sep 17, 2016 at 7:21 AM, sairam75 <> 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

Reply via email to