You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Seb- <se...@gmail.com> on 2009/08/29 21:18:25 UTC
Re: Transaction and Multicast() or to() AND to() ?
Hi Claus,
Do you have a work around to get transacted (basically transaction) working
with multiple threads.
ie get this from TransactionalClientDataSourceTest (where fails and/or okay
route have threads(x)) to rollback:
from("direct:shouldrollback").policy(required).
to("direct:okay").
to("direct:fail");
from("direct:okay").policy(required).
setBody(constant("Tiger in
Action")).beanRef("bookService").
setBody(constant("Elephant in
Action")).beanRef("bookService");
// set the required policy for this route
from("direct:fail").threads(5).policy(required).
setBody(constant("Tiger in
Action")).beanRef("bookService").
setBody(constant("Donkey in
Action")).beanRef("bookService");
Thanks,
Sébastien.
Claus Ibsen-2 wrote:
>
> On Tue, May 19, 2009 at 9:58 AM, Charles Moulliard <cm...@gmail.com>
> wrote:
>> Thanks Claus.
>>
>> Additional question :
>>
>> Can two routes be part of the same transaction ?
> Yes as long as they run in the same thread, eg as you do link them with
> direct.
> Do not use seda as it will break it into 2 threads.
>
> Spring TX manager uses the same thread for its TX management.
>
>
>>
>> ex :
>>
>> <route>
>> <from uri="activemq:queue:order.in"/>
>> <transacted/>
>> <to uri="bean:orderService?method=validate"/>
>> <to uri="direct:processOrder"/>
>> </route>
>>
>> <route>
>> <from uri="direct:processOrder"/>
>> <to uri="bean:orderService?method=process"/>
>> <to uri="activemq:queue:order.out"/>
>> </route>
>>
>> Regards,
>>
>>
>> Charles Moulliard
>> Senior Enterprise Architect
>> Apache Camel Committer
>>
>> *****************************
>> blog : http://cmoulliard.blogspot.com
>>
>>
>> On Tue, May 19, 2009 at 9:43 AM, Claus Ibsen <cl...@gmail.com>
>> wrote:
>>
>>> On Tue, May 19, 2009 at 9:11 AM, Charles Moulliard
>>> <cm...@gmail.com>
>>> wrote:
>>> > Hi,
>>> >
>>> > I would like to know if the transactional behavior of camel/spring
>>> will
>>> be
>>> > the same comparing the two next routes :
>>> >
>>> > 1) Multicast
>>> >
>>> > from()
>>> > transacted()
>>> > multicast(
>>> > to(bean:update DB)
>>> > to(queue:IN)
>>> > )
>>> >
>>> > 2) To() and to()
>>> >
>>> > from()
>>> > transacted()
>>> > to(bean:update DB)
>>> > to(queue:IN)
>>> >
>>>
>>> Yes the TX is the same.
>>>
>>>
>>> > Does it make sense to multicast messages when we want that data
>>> > updated/inserted DB are rollbacked if an error occurs during creation
>>> of
>>> the
>>> > message on the queue OR messages removed from the queue if an errors
>>> occurs
>>> > during DB update ?
>>>
>>> Spring TX manager will rollback the TX if it was marked for rollback
>>> or it caughts a runtime exception.
>>> So whatever you from the transacted() onwards will occur in the same TX.
>>>
>>> Using either .to or .multicast has really nothing to do with TX.
>>>
>>> The former is the Pipes And Filters EIP where output from the previous
>>> is input to the next and so forth.
>>> The latter is the Recipient List EIP where you send the *same* message
>>> to multiple recipients.
>>>
>>>
>>> >
>>> > Regards,
>>> >
>>> > Charles Moulliard
>>> > Senior Enterprise Architect
>>> > Apache Camel Committer
>>> >
>>> > *****************************
>>> > blog : http://cmoulliard.blogspot.com
>>> >
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25205618.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Transaction and Multicast() or to() AND to() ?
Posted by Seb- <se...@gmail.com>.
I see, yes I can keep the jdbc stuff in the same thread (possibly I will add
an entry route and end route dealing with the jdbc stuff).
Thank you very much for your help!
And keep on the good job on camel.
Claus Ibsen-2 wrote:
>
> On Sun, Aug 30, 2009 at 11:21 AM, Seb-<se...@gmail.com> wrote:
>>
>> The process do heavy cpu/time consuming process for each message it
>> receives,
>> then it sets the Exchange with the result.
>> It is parallelized to maximize the throughput. And it should be
>> transacted
>> from 1st endpoint to last one as the message will be processed through
>> other
>> routes (which might be multithreaded aswell), and if the whole route path
>> executed without any exception then a remove/insert will occur in the
>> database (just like the TransactionalClientDataSourceTest example).
>>
>
> If you can keep the JDBC stuff in the same thread as the starting
> thread (the one that has the policy(required) = the spring TX manager)
> then it should not matter if the CPU jobs are done in other threads.
> As long all what Spring TX manager needs to leverage is done from the
> same thread.
>
> In reality one a few transports supports TX such as JMS and JDBC. If
> you are not using JMS then its only left with JDBC.
> How much do you need to use the JDBC? If its only the last operation
> doing either insert/remove then its easier.
>
> I suggest to create a smaller unit test prototype with a route path
> simulating what you want to do.
>
>
>
>
>>
>> Claus Ibsen-2 wrote:
>>>
>>> On Sun, Aug 30, 2009 at 9:58 AM, Seb-<se...@gmail.com> wrote:
>>>>
>>>> In fact the input is not a JMS Queue. It's just that I need several
>>>> threads
>>>> to parallelize a .process().
>>>>
>>>
>>> What does the process do? Depending on what it does you could do it
>>> and still use transactions.
>>> Its just that the parallel tasks are using another thread and thus
>>> spring TX is affected.
>>>
>>>
>>>
>>>>
>>>> Claus Ibsen-2 wrote:
>>>>>
>>>>> On Sat, Aug 29, 2009 at 9:18 PM, Seb-<se...@gmail.com> wrote:
>>>>>>
>>>>>> Hi Claus,
>>>>>> Do you have a work around to get transacted (basically transaction)
>>>>>> working
>>>>>> with multiple threads.
>>>>>> ie get this from TransactionalClientDataSourceTest (where fails
>>>>>> and/or
>>>>>> okay
>>>>>> route have threads(x)) to rollback:
>>>>>>
>>>>>
>>>>> No that is not possible as its spring transaction that is doing the
>>>>> actual TX and it only supports doing that in the same synchronous
>>>>> thread.
>>>>>
>>>>> But if you input is from a JMS queue then set the
>>>>> concurrentConsumers=5 on the JMS endpoint and you have 5 threads at
>>>>> same time running in their own thread which all can be transacted.
>>>>>
>>>>>
>>>>>> from("direct:shouldrollback").policy(required).
>>>>>> to("direct:okay").
>>>>>> to("direct:fail");
>>>>>>
>>>>>> from("direct:okay").policy(required).
>>>>>> setBody(constant("Tiger in
>>>>>> Action")).beanRef("bookService").
>>>>>> setBody(constant("Elephant in
>>>>>> Action")).beanRef("bookService");
>>>>>>
>>>>>> // set the required policy for this route
>>>>>> from("direct:fail").threads(5).policy(required).
>>>>>> setBody(constant("Tiger in
>>>>>> Action")).beanRef("bookService").
>>>>>> setBody(constant("Donkey in
>>>>>> Action")).beanRef("bookService");
>>>>>>
>>>>>> Thanks,
>>>>>> Sébastien.
>>>>>>
>>>>>>
>>>>>> Claus Ibsen-2 wrote:
>>>>>>>
>>>>>>> On Tue, May 19, 2009 at 9:58 AM, Charles Moulliard
>>>>>>> <cm...@gmail.com>
>>>>>>> wrote:
>>>>>>>> Thanks Claus.
>>>>>>>>
>>>>>>>> Additional question :
>>>>>>>>
>>>>>>>> Can two routes be part of the same transaction ?
>>>>>>> Yes as long as they run in the same thread, eg as you do link them
>>>>>>> with
>>>>>>> direct.
>>>>>>> Do not use seda as it will break it into 2 threads.
>>>>>>>
>>>>>>> Spring TX manager uses the same thread for its TX management.
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> ex :
>>>>>>>>
>>>>>>>> <route>
>>>>>>>> <from uri="activemq:queue:order.in"/>
>>>>>>>> <transacted/>
>>>>>>>> <to uri="bean:orderService?method=validate"/>
>>>>>>>> <to uri="direct:processOrder"/>
>>>>>>>> </route>
>>>>>>>>
>>>>>>>> <route>
>>>>>>>> <from uri="direct:processOrder"/>
>>>>>>>> <to uri="bean:orderService?method=process"/>
>>>>>>>> <to uri="activemq:queue:order.out"/>
>>>>>>>> </route>
>>>>>>>>
>>>>>>>> Regards,
>>>>>>>>
>>>>>>>>
>>>>>>>> Charles Moulliard
>>>>>>>> Senior Enterprise Architect
>>>>>>>> Apache Camel Committer
>>>>>>>>
>>>>>>>> *****************************
>>>>>>>> blog : http://cmoulliard.blogspot.com
>>>>>>>>
>>>>>>>>
>>>>>>>> On Tue, May 19, 2009 at 9:43 AM, Claus Ibsen
>>>>>>>> <cl...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> On Tue, May 19, 2009 at 9:11 AM, Charles Moulliard
>>>>>>>>> <cm...@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> > Hi,
>>>>>>>>> >
>>>>>>>>> > I would like to know if the transactional behavior of
>>>>>>>>> camel/spring
>>>>>>>>> will
>>>>>>>>> be
>>>>>>>>> > the same comparing the two next routes :
>>>>>>>>> >
>>>>>>>>> > 1) Multicast
>>>>>>>>> >
>>>>>>>>> > from()
>>>>>>>>> > transacted()
>>>>>>>>> > multicast(
>>>>>>>>> > to(bean:update DB)
>>>>>>>>> > to(queue:IN)
>>>>>>>>> > )
>>>>>>>>> >
>>>>>>>>> > 2) To() and to()
>>>>>>>>> >
>>>>>>>>> > from()
>>>>>>>>> > transacted()
>>>>>>>>> > to(bean:update DB)
>>>>>>>>> > to(queue:IN)
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>> Yes the TX is the same.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> > Does it make sense to multicast messages when we want that data
>>>>>>>>> > updated/inserted DB are rollbacked if an error occurs during
>>>>>>>>> creation
>>>>>>>>> of
>>>>>>>>> the
>>>>>>>>> > message on the queue OR messages removed from the queue if an
>>>>>>>>> errors
>>>>>>>>> occurs
>>>>>>>>> > during DB update ?
>>>>>>>>>
>>>>>>>>> Spring TX manager will rollback the TX if it was marked for
>>>>>>>>> rollback
>>>>>>>>> or it caughts a runtime exception.
>>>>>>>>> So whatever you from the transacted() onwards will occur in the
>>>>>>>>> same
>>>>>>>>> TX.
>>>>>>>>>
>>>>>>>>> Using either .to or .multicast has really nothing to do with TX.
>>>>>>>>>
>>>>>>>>> The former is the Pipes And Filters EIP where output from the
>>>>>>>>> previous
>>>>>>>>> is input to the next and so forth.
>>>>>>>>> The latter is the Recipient List EIP where you send the *same*
>>>>>>>>> message
>>>>>>>>> to multiple recipients.
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> >
>>>>>>>>> > Regards,
>>>>>>>>> >
>>>>>>>>> > Charles Moulliard
>>>>>>>>> > Senior Enterprise Architect
>>>>>>>>> > Apache Camel Committer
>>>>>>>>> >
>>>>>>>>> > *****************************
>>>>>>>>> > blog : http://cmoulliard.blogspot.com
>>>>>>>>> >
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> --
>>>>>>>>> Claus Ibsen
>>>>>>>>> Apache Camel Committer
>>>>>>>>>
>>>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> Apache Camel Committer
>>>>>>>
>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>
>>>>>>>
>>>>>>
>>>>>> --
>>>>>> View this message in context:
>>>>>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25205618.html
>>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>>
>>>>> Open Source Integration: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Twitter: http://twitter.com/davsclaus
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209498.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209959.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25210156.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Transaction and Multicast() or to() AND to() ?
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Aug 30, 2009 at 11:21 AM, Seb-<se...@gmail.com> wrote:
>
> The process do heavy cpu/time consuming process for each message it receives,
> then it sets the Exchange with the result.
> It is parallelized to maximize the throughput. And it should be transacted
> from 1st endpoint to last one as the message will be processed through other
> routes (which might be multithreaded aswell), and if the whole route path
> executed without any exception then a remove/insert will occur in the
> database (just like the TransactionalClientDataSourceTest example).
>
If you can keep the JDBC stuff in the same thread as the starting
thread (the one that has the policy(required) = the spring TX manager)
then it should not matter if the CPU jobs are done in other threads.
As long all what Spring TX manager needs to leverage is done from the
same thread.
In reality one a few transports supports TX such as JMS and JDBC. If
you are not using JMS then its only left with JDBC.
How much do you need to use the JDBC? If its only the last operation
doing either insert/remove then its easier.
I suggest to create a smaller unit test prototype with a route path
simulating what you want to do.
>
> Claus Ibsen-2 wrote:
>>
>> On Sun, Aug 30, 2009 at 9:58 AM, Seb-<se...@gmail.com> wrote:
>>>
>>> In fact the input is not a JMS Queue. It's just that I need several
>>> threads
>>> to parallelize a .process().
>>>
>>
>> What does the process do? Depending on what it does you could do it
>> and still use transactions.
>> Its just that the parallel tasks are using another thread and thus
>> spring TX is affected.
>>
>>
>>
>>>
>>> Claus Ibsen-2 wrote:
>>>>
>>>> On Sat, Aug 29, 2009 at 9:18 PM, Seb-<se...@gmail.com> wrote:
>>>>>
>>>>> Hi Claus,
>>>>> Do you have a work around to get transacted (basically transaction)
>>>>> working
>>>>> with multiple threads.
>>>>> ie get this from TransactionalClientDataSourceTest (where fails and/or
>>>>> okay
>>>>> route have threads(x)) to rollback:
>>>>>
>>>>
>>>> No that is not possible as its spring transaction that is doing the
>>>> actual TX and it only supports doing that in the same synchronous
>>>> thread.
>>>>
>>>> But if you input is from a JMS queue then set the
>>>> concurrentConsumers=5 on the JMS endpoint and you have 5 threads at
>>>> same time running in their own thread which all can be transacted.
>>>>
>>>>
>>>>> from("direct:shouldrollback").policy(required).
>>>>> to("direct:okay").
>>>>> to("direct:fail");
>>>>>
>>>>> from("direct:okay").policy(required).
>>>>> setBody(constant("Tiger in
>>>>> Action")).beanRef("bookService").
>>>>> setBody(constant("Elephant in
>>>>> Action")).beanRef("bookService");
>>>>>
>>>>> // set the required policy for this route
>>>>> from("direct:fail").threads(5).policy(required).
>>>>> setBody(constant("Tiger in
>>>>> Action")).beanRef("bookService").
>>>>> setBody(constant("Donkey in
>>>>> Action")).beanRef("bookService");
>>>>>
>>>>> Thanks,
>>>>> Sébastien.
>>>>>
>>>>>
>>>>> Claus Ibsen-2 wrote:
>>>>>>
>>>>>> On Tue, May 19, 2009 at 9:58 AM, Charles Moulliard
>>>>>> <cm...@gmail.com>
>>>>>> wrote:
>>>>>>> Thanks Claus.
>>>>>>>
>>>>>>> Additional question :
>>>>>>>
>>>>>>> Can two routes be part of the same transaction ?
>>>>>> Yes as long as they run in the same thread, eg as you do link them
>>>>>> with
>>>>>> direct.
>>>>>> Do not use seda as it will break it into 2 threads.
>>>>>>
>>>>>> Spring TX manager uses the same thread for its TX management.
>>>>>>
>>>>>>
>>>>>>>
>>>>>>> ex :
>>>>>>>
>>>>>>> <route>
>>>>>>> <from uri="activemq:queue:order.in"/>
>>>>>>> <transacted/>
>>>>>>> <to uri="bean:orderService?method=validate"/>
>>>>>>> <to uri="direct:processOrder"/>
>>>>>>> </route>
>>>>>>>
>>>>>>> <route>
>>>>>>> <from uri="direct:processOrder"/>
>>>>>>> <to uri="bean:orderService?method=process"/>
>>>>>>> <to uri="activemq:queue:order.out"/>
>>>>>>> </route>
>>>>>>>
>>>>>>> Regards,
>>>>>>>
>>>>>>>
>>>>>>> Charles Moulliard
>>>>>>> Senior Enterprise Architect
>>>>>>> Apache Camel Committer
>>>>>>>
>>>>>>> *****************************
>>>>>>> blog : http://cmoulliard.blogspot.com
>>>>>>>
>>>>>>>
>>>>>>> On Tue, May 19, 2009 at 9:43 AM, Claus Ibsen <cl...@gmail.com>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> On Tue, May 19, 2009 at 9:11 AM, Charles Moulliard
>>>>>>>> <cm...@gmail.com>
>>>>>>>> wrote:
>>>>>>>> > Hi,
>>>>>>>> >
>>>>>>>> > I would like to know if the transactional behavior of camel/spring
>>>>>>>> will
>>>>>>>> be
>>>>>>>> > the same comparing the two next routes :
>>>>>>>> >
>>>>>>>> > 1) Multicast
>>>>>>>> >
>>>>>>>> > from()
>>>>>>>> > transacted()
>>>>>>>> > multicast(
>>>>>>>> > to(bean:update DB)
>>>>>>>> > to(queue:IN)
>>>>>>>> > )
>>>>>>>> >
>>>>>>>> > 2) To() and to()
>>>>>>>> >
>>>>>>>> > from()
>>>>>>>> > transacted()
>>>>>>>> > to(bean:update DB)
>>>>>>>> > to(queue:IN)
>>>>>>>> >
>>>>>>>>
>>>>>>>> Yes the TX is the same.
>>>>>>>>
>>>>>>>>
>>>>>>>> > Does it make sense to multicast messages when we want that data
>>>>>>>> > updated/inserted DB are rollbacked if an error occurs during
>>>>>>>> creation
>>>>>>>> of
>>>>>>>> the
>>>>>>>> > message on the queue OR messages removed from the queue if an
>>>>>>>> errors
>>>>>>>> occurs
>>>>>>>> > during DB update ?
>>>>>>>>
>>>>>>>> Spring TX manager will rollback the TX if it was marked for rollback
>>>>>>>> or it caughts a runtime exception.
>>>>>>>> So whatever you from the transacted() onwards will occur in the same
>>>>>>>> TX.
>>>>>>>>
>>>>>>>> Using either .to or .multicast has really nothing to do with TX.
>>>>>>>>
>>>>>>>> The former is the Pipes And Filters EIP where output from the
>>>>>>>> previous
>>>>>>>> is input to the next and so forth.
>>>>>>>> The latter is the Recipient List EIP where you send the *same*
>>>>>>>> message
>>>>>>>> to multiple recipients.
>>>>>>>>
>>>>>>>>
>>>>>>>> >
>>>>>>>> > Regards,
>>>>>>>> >
>>>>>>>> > Charles Moulliard
>>>>>>>> > Senior Enterprise Architect
>>>>>>>> > Apache Camel Committer
>>>>>>>> >
>>>>>>>> > *****************************
>>>>>>>> > blog : http://cmoulliard.blogspot.com
>>>>>>>> >
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> Apache Camel Committer
>>>>>>>>
>>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> Apache Camel Committer
>>>>>>
>>>>>> Open Source Integration: http://fusesource.com
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> View this message in context:
>>>>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25205618.html
>>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209498.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209959.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Transaction and Multicast() or to() AND to() ?
Posted by Seb- <se...@gmail.com>.
The process do heavy cpu/time consuming process for each message it receives,
then it sets the Exchange with the result.
It is parallelized to maximize the throughput. And it should be transacted
from 1st endpoint to last one as the message will be processed through other
routes (which might be multithreaded aswell), and if the whole route path
executed without any exception then a remove/insert will occur in the
database (just like the TransactionalClientDataSourceTest example).
Claus Ibsen-2 wrote:
>
> On Sun, Aug 30, 2009 at 9:58 AM, Seb-<se...@gmail.com> wrote:
>>
>> In fact the input is not a JMS Queue. It's just that I need several
>> threads
>> to parallelize a .process().
>>
>
> What does the process do? Depending on what it does you could do it
> and still use transactions.
> Its just that the parallel tasks are using another thread and thus
> spring TX is affected.
>
>
>
>>
>> Claus Ibsen-2 wrote:
>>>
>>> On Sat, Aug 29, 2009 at 9:18 PM, Seb-<se...@gmail.com> wrote:
>>>>
>>>> Hi Claus,
>>>> Do you have a work around to get transacted (basically transaction)
>>>> working
>>>> with multiple threads.
>>>> ie get this from TransactionalClientDataSourceTest (where fails and/or
>>>> okay
>>>> route have threads(x)) to rollback:
>>>>
>>>
>>> No that is not possible as its spring transaction that is doing the
>>> actual TX and it only supports doing that in the same synchronous
>>> thread.
>>>
>>> But if you input is from a JMS queue then set the
>>> concurrentConsumers=5 on the JMS endpoint and you have 5 threads at
>>> same time running in their own thread which all can be transacted.
>>>
>>>
>>>> from("direct:shouldrollback").policy(required).
>>>> to("direct:okay").
>>>> to("direct:fail");
>>>>
>>>> from("direct:okay").policy(required).
>>>> setBody(constant("Tiger in
>>>> Action")).beanRef("bookService").
>>>> setBody(constant("Elephant in
>>>> Action")).beanRef("bookService");
>>>>
>>>> // set the required policy for this route
>>>> from("direct:fail").threads(5).policy(required).
>>>> setBody(constant("Tiger in
>>>> Action")).beanRef("bookService").
>>>> setBody(constant("Donkey in
>>>> Action")).beanRef("bookService");
>>>>
>>>> Thanks,
>>>> Sébastien.
>>>>
>>>>
>>>> Claus Ibsen-2 wrote:
>>>>>
>>>>> On Tue, May 19, 2009 at 9:58 AM, Charles Moulliard
>>>>> <cm...@gmail.com>
>>>>> wrote:
>>>>>> Thanks Claus.
>>>>>>
>>>>>> Additional question :
>>>>>>
>>>>>> Can two routes be part of the same transaction ?
>>>>> Yes as long as they run in the same thread, eg as you do link them
>>>>> with
>>>>> direct.
>>>>> Do not use seda as it will break it into 2 threads.
>>>>>
>>>>> Spring TX manager uses the same thread for its TX management.
>>>>>
>>>>>
>>>>>>
>>>>>> ex :
>>>>>>
>>>>>> <route>
>>>>>> <from uri="activemq:queue:order.in"/>
>>>>>> <transacted/>
>>>>>> <to uri="bean:orderService?method=validate"/>
>>>>>> <to uri="direct:processOrder"/>
>>>>>> </route>
>>>>>>
>>>>>> <route>
>>>>>> <from uri="direct:processOrder"/>
>>>>>> <to uri="bean:orderService?method=process"/>
>>>>>> <to uri="activemq:queue:order.out"/>
>>>>>> </route>
>>>>>>
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>> Charles Moulliard
>>>>>> Senior Enterprise Architect
>>>>>> Apache Camel Committer
>>>>>>
>>>>>> *****************************
>>>>>> blog : http://cmoulliard.blogspot.com
>>>>>>
>>>>>>
>>>>>> On Tue, May 19, 2009 at 9:43 AM, Claus Ibsen <cl...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> On Tue, May 19, 2009 at 9:11 AM, Charles Moulliard
>>>>>>> <cm...@gmail.com>
>>>>>>> wrote:
>>>>>>> > Hi,
>>>>>>> >
>>>>>>> > I would like to know if the transactional behavior of camel/spring
>>>>>>> will
>>>>>>> be
>>>>>>> > the same comparing the two next routes :
>>>>>>> >
>>>>>>> > 1) Multicast
>>>>>>> >
>>>>>>> > from()
>>>>>>> > transacted()
>>>>>>> > multicast(
>>>>>>> > to(bean:update DB)
>>>>>>> > to(queue:IN)
>>>>>>> > )
>>>>>>> >
>>>>>>> > 2) To() and to()
>>>>>>> >
>>>>>>> > from()
>>>>>>> > transacted()
>>>>>>> > to(bean:update DB)
>>>>>>> > to(queue:IN)
>>>>>>> >
>>>>>>>
>>>>>>> Yes the TX is the same.
>>>>>>>
>>>>>>>
>>>>>>> > Does it make sense to multicast messages when we want that data
>>>>>>> > updated/inserted DB are rollbacked if an error occurs during
>>>>>>> creation
>>>>>>> of
>>>>>>> the
>>>>>>> > message on the queue OR messages removed from the queue if an
>>>>>>> errors
>>>>>>> occurs
>>>>>>> > during DB update ?
>>>>>>>
>>>>>>> Spring TX manager will rollback the TX if it was marked for rollback
>>>>>>> or it caughts a runtime exception.
>>>>>>> So whatever you from the transacted() onwards will occur in the same
>>>>>>> TX.
>>>>>>>
>>>>>>> Using either .to or .multicast has really nothing to do with TX.
>>>>>>>
>>>>>>> The former is the Pipes And Filters EIP where output from the
>>>>>>> previous
>>>>>>> is input to the next and so forth.
>>>>>>> The latter is the Recipient List EIP where you send the *same*
>>>>>>> message
>>>>>>> to multiple recipients.
>>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>> > Regards,
>>>>>>> >
>>>>>>> > Charles Moulliard
>>>>>>> > Senior Enterprise Architect
>>>>>>> > Apache Camel Committer
>>>>>>> >
>>>>>>> > *****************************
>>>>>>> > blog : http://cmoulliard.blogspot.com
>>>>>>> >
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> Apache Camel Committer
>>>>>>>
>>>>>>> Open Source Integration: http://fusesource.com
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>>
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>>
>>>>> Open Source Integration: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Twitter: http://twitter.com/davsclaus
>>>>>
>>>>>
>>>>
>>>> --
>>>> View this message in context:
>>>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25205618.html
>>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209498.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209959.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Transaction and Multicast() or to() AND to() ?
Posted by Claus Ibsen <cl...@gmail.com>.
On Sun, Aug 30, 2009 at 9:58 AM, Seb-<se...@gmail.com> wrote:
>
> In fact the input is not a JMS Queue. It's just that I need several threads
> to parallelize a .process().
>
What does the process do? Depending on what it does you could do it
and still use transactions.
Its just that the parallel tasks are using another thread and thus
spring TX is affected.
>
> Claus Ibsen-2 wrote:
>>
>> On Sat, Aug 29, 2009 at 9:18 PM, Seb-<se...@gmail.com> wrote:
>>>
>>> Hi Claus,
>>> Do you have a work around to get transacted (basically transaction)
>>> working
>>> with multiple threads.
>>> ie get this from TransactionalClientDataSourceTest (where fails and/or
>>> okay
>>> route have threads(x)) to rollback:
>>>
>>
>> No that is not possible as its spring transaction that is doing the
>> actual TX and it only supports doing that in the same synchronous
>> thread.
>>
>> But if you input is from a JMS queue then set the
>> concurrentConsumers=5 on the JMS endpoint and you have 5 threads at
>> same time running in their own thread which all can be transacted.
>>
>>
>>> from("direct:shouldrollback").policy(required).
>>> to("direct:okay").
>>> to("direct:fail");
>>>
>>> from("direct:okay").policy(required).
>>> setBody(constant("Tiger in
>>> Action")).beanRef("bookService").
>>> setBody(constant("Elephant in
>>> Action")).beanRef("bookService");
>>>
>>> // set the required policy for this route
>>> from("direct:fail").threads(5).policy(required).
>>> setBody(constant("Tiger in
>>> Action")).beanRef("bookService").
>>> setBody(constant("Donkey in
>>> Action")).beanRef("bookService");
>>>
>>> Thanks,
>>> Sébastien.
>>>
>>>
>>> Claus Ibsen-2 wrote:
>>>>
>>>> On Tue, May 19, 2009 at 9:58 AM, Charles Moulliard
>>>> <cm...@gmail.com>
>>>> wrote:
>>>>> Thanks Claus.
>>>>>
>>>>> Additional question :
>>>>>
>>>>> Can two routes be part of the same transaction ?
>>>> Yes as long as they run in the same thread, eg as you do link them with
>>>> direct.
>>>> Do not use seda as it will break it into 2 threads.
>>>>
>>>> Spring TX manager uses the same thread for its TX management.
>>>>
>>>>
>>>>>
>>>>> ex :
>>>>>
>>>>> <route>
>>>>> <from uri="activemq:queue:order.in"/>
>>>>> <transacted/>
>>>>> <to uri="bean:orderService?method=validate"/>
>>>>> <to uri="direct:processOrder"/>
>>>>> </route>
>>>>>
>>>>> <route>
>>>>> <from uri="direct:processOrder"/>
>>>>> <to uri="bean:orderService?method=process"/>
>>>>> <to uri="activemq:queue:order.out"/>
>>>>> </route>
>>>>>
>>>>> Regards,
>>>>>
>>>>>
>>>>> Charles Moulliard
>>>>> Senior Enterprise Architect
>>>>> Apache Camel Committer
>>>>>
>>>>> *****************************
>>>>> blog : http://cmoulliard.blogspot.com
>>>>>
>>>>>
>>>>> On Tue, May 19, 2009 at 9:43 AM, Claus Ibsen <cl...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> On Tue, May 19, 2009 at 9:11 AM, Charles Moulliard
>>>>>> <cm...@gmail.com>
>>>>>> wrote:
>>>>>> > Hi,
>>>>>> >
>>>>>> > I would like to know if the transactional behavior of camel/spring
>>>>>> will
>>>>>> be
>>>>>> > the same comparing the two next routes :
>>>>>> >
>>>>>> > 1) Multicast
>>>>>> >
>>>>>> > from()
>>>>>> > transacted()
>>>>>> > multicast(
>>>>>> > to(bean:update DB)
>>>>>> > to(queue:IN)
>>>>>> > )
>>>>>> >
>>>>>> > 2) To() and to()
>>>>>> >
>>>>>> > from()
>>>>>> > transacted()
>>>>>> > to(bean:update DB)
>>>>>> > to(queue:IN)
>>>>>> >
>>>>>>
>>>>>> Yes the TX is the same.
>>>>>>
>>>>>>
>>>>>> > Does it make sense to multicast messages when we want that data
>>>>>> > updated/inserted DB are rollbacked if an error occurs during
>>>>>> creation
>>>>>> of
>>>>>> the
>>>>>> > message on the queue OR messages removed from the queue if an errors
>>>>>> occurs
>>>>>> > during DB update ?
>>>>>>
>>>>>> Spring TX manager will rollback the TX if it was marked for rollback
>>>>>> or it caughts a runtime exception.
>>>>>> So whatever you from the transacted() onwards will occur in the same
>>>>>> TX.
>>>>>>
>>>>>> Using either .to or .multicast has really nothing to do with TX.
>>>>>>
>>>>>> The former is the Pipes And Filters EIP where output from the previous
>>>>>> is input to the next and so forth.
>>>>>> The latter is the Recipient List EIP where you send the *same* message
>>>>>> to multiple recipients.
>>>>>>
>>>>>>
>>>>>> >
>>>>>> > Regards,
>>>>>> >
>>>>>> > Charles Moulliard
>>>>>> > Senior Enterprise Architect
>>>>>> > Apache Camel Committer
>>>>>> >
>>>>>> > *****************************
>>>>>> > blog : http://cmoulliard.blogspot.com
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> Apache Camel Committer
>>>>>>
>>>>>> Open Source Integration: http://fusesource.com
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>> Twitter: http://twitter.com/davsclaus
>>>>>>
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>>
>>>>
>>>
>>> --
>>> View this message in context:
>>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25205618.html
>>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209498.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus
Re: Transaction and Multicast() or to() AND to() ?
Posted by Seb- <se...@gmail.com>.
In fact the input is not a JMS Queue. It's just that I need several threads
to parallelize a .process().
Claus Ibsen-2 wrote:
>
> On Sat, Aug 29, 2009 at 9:18 PM, Seb-<se...@gmail.com> wrote:
>>
>> Hi Claus,
>> Do you have a work around to get transacted (basically transaction)
>> working
>> with multiple threads.
>> ie get this from TransactionalClientDataSourceTest (where fails and/or
>> okay
>> route have threads(x)) to rollback:
>>
>
> No that is not possible as its spring transaction that is doing the
> actual TX and it only supports doing that in the same synchronous
> thread.
>
> But if you input is from a JMS queue then set the
> concurrentConsumers=5 on the JMS endpoint and you have 5 threads at
> same time running in their own thread which all can be transacted.
>
>
>> from("direct:shouldrollback").policy(required).
>> to("direct:okay").
>> to("direct:fail");
>>
>> from("direct:okay").policy(required).
>> setBody(constant("Tiger in
>> Action")).beanRef("bookService").
>> setBody(constant("Elephant in
>> Action")).beanRef("bookService");
>>
>> // set the required policy for this route
>> from("direct:fail").threads(5).policy(required).
>> setBody(constant("Tiger in
>> Action")).beanRef("bookService").
>> setBody(constant("Donkey in
>> Action")).beanRef("bookService");
>>
>> Thanks,
>> Sébastien.
>>
>>
>> Claus Ibsen-2 wrote:
>>>
>>> On Tue, May 19, 2009 at 9:58 AM, Charles Moulliard
>>> <cm...@gmail.com>
>>> wrote:
>>>> Thanks Claus.
>>>>
>>>> Additional question :
>>>>
>>>> Can two routes be part of the same transaction ?
>>> Yes as long as they run in the same thread, eg as you do link them with
>>> direct.
>>> Do not use seda as it will break it into 2 threads.
>>>
>>> Spring TX manager uses the same thread for its TX management.
>>>
>>>
>>>>
>>>> ex :
>>>>
>>>> <route>
>>>> <from uri="activemq:queue:order.in"/>
>>>> <transacted/>
>>>> <to uri="bean:orderService?method=validate"/>
>>>> <to uri="direct:processOrder"/>
>>>> </route>
>>>>
>>>> <route>
>>>> <from uri="direct:processOrder"/>
>>>> <to uri="bean:orderService?method=process"/>
>>>> <to uri="activemq:queue:order.out"/>
>>>> </route>
>>>>
>>>> Regards,
>>>>
>>>>
>>>> Charles Moulliard
>>>> Senior Enterprise Architect
>>>> Apache Camel Committer
>>>>
>>>> *****************************
>>>> blog : http://cmoulliard.blogspot.com
>>>>
>>>>
>>>> On Tue, May 19, 2009 at 9:43 AM, Claus Ibsen <cl...@gmail.com>
>>>> wrote:
>>>>
>>>>> On Tue, May 19, 2009 at 9:11 AM, Charles Moulliard
>>>>> <cm...@gmail.com>
>>>>> wrote:
>>>>> > Hi,
>>>>> >
>>>>> > I would like to know if the transactional behavior of camel/spring
>>>>> will
>>>>> be
>>>>> > the same comparing the two next routes :
>>>>> >
>>>>> > 1) Multicast
>>>>> >
>>>>> > from()
>>>>> > transacted()
>>>>> > multicast(
>>>>> > to(bean:update DB)
>>>>> > to(queue:IN)
>>>>> > )
>>>>> >
>>>>> > 2) To() and to()
>>>>> >
>>>>> > from()
>>>>> > transacted()
>>>>> > to(bean:update DB)
>>>>> > to(queue:IN)
>>>>> >
>>>>>
>>>>> Yes the TX is the same.
>>>>>
>>>>>
>>>>> > Does it make sense to multicast messages when we want that data
>>>>> > updated/inserted DB are rollbacked if an error occurs during
>>>>> creation
>>>>> of
>>>>> the
>>>>> > message on the queue OR messages removed from the queue if an errors
>>>>> occurs
>>>>> > during DB update ?
>>>>>
>>>>> Spring TX manager will rollback the TX if it was marked for rollback
>>>>> or it caughts a runtime exception.
>>>>> So whatever you from the transacted() onwards will occur in the same
>>>>> TX.
>>>>>
>>>>> Using either .to or .multicast has really nothing to do with TX.
>>>>>
>>>>> The former is the Pipes And Filters EIP where output from the previous
>>>>> is input to the next and so forth.
>>>>> The latter is the Recipient List EIP where you send the *same* message
>>>>> to multiple recipients.
>>>>>
>>>>>
>>>>> >
>>>>> > Regards,
>>>>> >
>>>>> > Charles Moulliard
>>>>> > Senior Enterprise Architect
>>>>> > Apache Camel Committer
>>>>> >
>>>>> > *****************************
>>>>> > blog : http://cmoulliard.blogspot.com
>>>>> >
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> Apache Camel Committer
>>>>>
>>>>> Open Source Integration: http://fusesource.com
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Twitter: http://twitter.com/davsclaus
>>>>>
>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> Apache Camel Committer
>>>
>>> Open Source Integration: http://fusesource.com
>>> Blog: http://davsclaus.blogspot.com/
>>> Twitter: http://twitter.com/davsclaus
>>>
>>>
>>
>> --
>> View this message in context:
>> http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25205618.html
>> Sent from the Camel - Users mailing list archive at Nabble.com.
>>
>>
>
>
>
> --
> Claus Ibsen
> Apache Camel Committer
>
> Open Source Integration: http://fusesource.com
> Blog: http://davsclaus.blogspot.com/
> Twitter: http://twitter.com/davsclaus
>
>
--
View this message in context: http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25209498.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: Transaction and Multicast() or to() AND to() ?
Posted by Claus Ibsen <cl...@gmail.com>.
On Sat, Aug 29, 2009 at 9:18 PM, Seb-<se...@gmail.com> wrote:
>
> Hi Claus,
> Do you have a work around to get transacted (basically transaction) working
> with multiple threads.
> ie get this from TransactionalClientDataSourceTest (where fails and/or okay
> route have threads(x)) to rollback:
>
No that is not possible as its spring transaction that is doing the
actual TX and it only supports doing that in the same synchronous
thread.
But if you input is from a JMS queue then set the
concurrentConsumers=5 on the JMS endpoint and you have 5 threads at
same time running in their own thread which all can be transacted.
> from("direct:shouldrollback").policy(required).
> to("direct:okay").
> to("direct:fail");
>
> from("direct:okay").policy(required).
> setBody(constant("Tiger in
> Action")).beanRef("bookService").
> setBody(constant("Elephant in
> Action")).beanRef("bookService");
>
> // set the required policy for this route
> from("direct:fail").threads(5).policy(required).
> setBody(constant("Tiger in
> Action")).beanRef("bookService").
> setBody(constant("Donkey in
> Action")).beanRef("bookService");
>
> Thanks,
> Sébastien.
>
>
> Claus Ibsen-2 wrote:
>>
>> On Tue, May 19, 2009 at 9:58 AM, Charles Moulliard <cm...@gmail.com>
>> wrote:
>>> Thanks Claus.
>>>
>>> Additional question :
>>>
>>> Can two routes be part of the same transaction ?
>> Yes as long as they run in the same thread, eg as you do link them with
>> direct.
>> Do not use seda as it will break it into 2 threads.
>>
>> Spring TX manager uses the same thread for its TX management.
>>
>>
>>>
>>> ex :
>>>
>>> <route>
>>> <from uri="activemq:queue:order.in"/>
>>> <transacted/>
>>> <to uri="bean:orderService?method=validate"/>
>>> <to uri="direct:processOrder"/>
>>> </route>
>>>
>>> <route>
>>> <from uri="direct:processOrder"/>
>>> <to uri="bean:orderService?method=process"/>
>>> <to uri="activemq:queue:order.out"/>
>>> </route>
>>>
>>> Regards,
>>>
>>>
>>> Charles Moulliard
>>> Senior Enterprise Architect
>>> Apache Camel Committer
>>>
>>> *****************************
>>> blog : http://cmoulliard.blogspot.com
>>>
>>>
>>> On Tue, May 19, 2009 at 9:43 AM, Claus Ibsen <cl...@gmail.com>
>>> wrote:
>>>
>>>> On Tue, May 19, 2009 at 9:11 AM, Charles Moulliard
>>>> <cm...@gmail.com>
>>>> wrote:
>>>> > Hi,
>>>> >
>>>> > I would like to know if the transactional behavior of camel/spring
>>>> will
>>>> be
>>>> > the same comparing the two next routes :
>>>> >
>>>> > 1) Multicast
>>>> >
>>>> > from()
>>>> > transacted()
>>>> > multicast(
>>>> > to(bean:update DB)
>>>> > to(queue:IN)
>>>> > )
>>>> >
>>>> > 2) To() and to()
>>>> >
>>>> > from()
>>>> > transacted()
>>>> > to(bean:update DB)
>>>> > to(queue:IN)
>>>> >
>>>>
>>>> Yes the TX is the same.
>>>>
>>>>
>>>> > Does it make sense to multicast messages when we want that data
>>>> > updated/inserted DB are rollbacked if an error occurs during creation
>>>> of
>>>> the
>>>> > message on the queue OR messages removed from the queue if an errors
>>>> occurs
>>>> > during DB update ?
>>>>
>>>> Spring TX manager will rollback the TX if it was marked for rollback
>>>> or it caughts a runtime exception.
>>>> So whatever you from the transacted() onwards will occur in the same TX.
>>>>
>>>> Using either .to or .multicast has really nothing to do with TX.
>>>>
>>>> The former is the Pipes And Filters EIP where output from the previous
>>>> is input to the next and so forth.
>>>> The latter is the Recipient List EIP where you send the *same* message
>>>> to multiple recipients.
>>>>
>>>>
>>>> >
>>>> > Regards,
>>>> >
>>>> > Charles Moulliard
>>>> > Senior Enterprise Architect
>>>> > Apache Camel Committer
>>>> >
>>>> > *****************************
>>>> > blog : http://cmoulliard.blogspot.com
>>>> >
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> Apache Camel Committer
>>>>
>>>> Open Source Integration: http://fusesource.com
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Twitter: http://twitter.com/davsclaus
>>>>
>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> Apache Camel Committer
>>
>> Open Source Integration: http://fusesource.com
>> Blog: http://davsclaus.blogspot.com/
>> Twitter: http://twitter.com/davsclaus
>>
>>
>
> --
> View this message in context: http://www.nabble.com/Transaction-and-Multicast%28%29-or-to%28%29-AND-to%28%29---tp23610919p25205618.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Claus Ibsen
Apache Camel Committer
Open Source Integration: http://fusesource.com
Blog: http://davsclaus.blogspot.com/
Twitter: http://twitter.com/davsclaus