You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by Hervé BARRAULT <he...@gmail.com> on 2012/01/27 14:27:58 UTC
JMS and transaction
Hi,
I have two question about a route, JMS and transactions.
The use is : one request response Web service put message on n queues
(using transaction ensure the message really put in all queues or no
one).
Does this route make sense (only "pseudo" route not all the stuff to
manage transaction i guess) ?
from("cxf:bean:myEndpoint").
.wireTap("direct:tap")
.process(myProcessor)
transacted("PROPAGATION_REQUIRES_NEW")
.multicast()
.parallelProcessing()
.recipientList(header("MY_HEADER"))
.end()
.process(myAnswerProcessor);
from(direct:tap).process(myOptionalProcessor);
If it could work, when is the transaction commit ?
Thanks for answers.
Regards
Hervé
Re: JMS and transaction
Posted by Claus Ibsen <cl...@gmail.com>.
Hi
You can have different queues for different styles
- queues which can safely be processed concurrently and out of order
- other queue(s) where messages must be processed in order
On Tue, Jan 31, 2012 at 11:00 AM, Hervé BARRAULT
<he...@gmail.com> wrote:
> Thanks for your accurate answers.
>
> I have seen messages groups but i have some messages which are out
> potential groups.
>
> So i have to deal with unordered messages. (or i should find a way to
> have multiconsumer the main time and some time for some known messages
> i should "downgrade" to only one consumer and then restart all
> consumers but it will not work ^^).
>
> Regards
> Hervé
>
> On 1/31/12, Claus Ibsen <cl...@gmail.com> wrote:
>> On Tue, Jan 31, 2012 at 10:00 AM, Hervé BARRAULT
>> <he...@gmail.com> wrote:
>>> Thanks,
>>> So, i should publish sequentially and can consume concurrently.
>>
>> Yeah, or public concurrently also. If ordering does not matter.
>>
>> Only if you need ordering of messages, and process concurrently you
>> can use message groups
>> http://activemq.apache.org/how-do-i-preserve-order-of-messages.html
>> http://activemq.apache.org/how-do-message-groups-compare-to-selectors.html
>> http://activemq.apache.org/message-groups.html
>>
>>
>>>
>>> As there is only direct component which is a synchronous call, I guess
>>> a transaction can work across multiple route but in one camel context.
>>>
>>
>> Yes that would work.
>>
>>> Am i wrong ?
>>
>> No.
>>
>>
>>>
>>>
>>> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>> On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
>>>> <he...@gmail.com> wrote:
>>>>> Hi,
>>>>> thanks for the quick answer.
>>>>>
>>>>>> It does not support batching, not async TX, etc.
>>>>>
>>>>> But does it supports TX and concurrentConsumers ?
>>>>>
>>>>> I have to multiply the number of consumers as they are slower than the
>>>>> producer.
>>>>>
>>>>
>>>> Yes.
>>>>
>>>>
>>>>>
>>>>> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>> On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
>>>>>> <he...@gmail.com> wrote:
>>>>>>> Hi, thanks for confirmation.
>>>>>>> So for publication, i should use a transactions with sequential
>>>>>>> mechanism.
>>>>>>>
>>>>>>> I have seen also on activeMQ documentation :
>>>>>>> http://activemq.apache.org/should-i-use-transactions.html :
>>>>>>> Its also worth noting that if you are using persistent messaging, the
>>>>>>> fastest way of using JMS is to actually use transactions and use
>>>>>>> batching ...
>>>>>>>
>>>>>>> Is this mechanism working when using concurrentConsumer ?
>>>>>>> Or should i choose between transaction and batching ?
>>>>>>>
>>>>>>
>>>>>> The camel-jms component is baked on top of Spring JMS which is generic
>>>>>> and limited in some areas.
>>>>>> It does not support batching, not async TX, etc.
>>>>>>
>>>>>> Alot of people just use it as is, and its fast enough for their
>>>>>> use-cases.
>>>>>> I suggest to use that, and do some testing to see if its fast enough
>>>>>> for
>>>>>> you.
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>> Thanks for answers
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Hervé
>>>>>>>
>>>>>>>
>>>>>>> On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>>> Spring Transaction does not support using multiple threads. The
>>>>>>>> transactional work should be done in the same thread, from spring TX
>>>>>>>> manager point of view.
>>>>>>>>
>>>>>>>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
>>>>>>>> <he...@gmail.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I found in archive that parallel processing is not compatible with
>>>>>>>>> transaction.
>>>>>>>>>
>>>>>>>>> Is it still relevant or is there a workaround ?
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>>
>>>>>>>>> Hervé
>>>>>>>>>
>>>>>>>>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>> I have two question about a route, JMS and transactions.
>>>>>>>>>>
>>>>>>>>>> The use is : one request response Web service put message on n
>>>>>>>>>> queues
>>>>>>>>>> (using transaction ensure the message really put in all queues or
>>>>>>>>>> no
>>>>>>>>>> one).
>>>>>>>>>>
>>>>>>>>>> Does this route make sense (only "pseudo" route not all the stuff
>>>>>>>>>> to
>>>>>>>>>> manage transaction i guess) ?
>>>>>>>>>>
>>>>>>>>>> from("cxf:bean:myEndpoint").
>>>>>>>>>> .wireTap("direct:tap")
>>>>>>>>>> .process(myProcessor)
>>>>>>>>>> transacted("PROPAGATION_REQUIRES_NEW")
>>>>>>>>>> .multicast()
>>>>>>>>>> .parallelProcessing()
>>>>>>>>>> .recipientList(header("MY_HEADER"))
>>>>>>>>>> .end()
>>>>>>>>>> .process(myAnswerProcessor);
>>>>>>>>>>
>>>>>>>>>> from(direct:tap).process(myOptionalProcessor);
>>>>>>>>>>
>>>>>>>>>> If it could work, when is the transaction commit ?
>>>>>>>>>>
>>>>>>>>>> Thanks for answers.
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Hervé
>>>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> --
>>>>>>>> Claus Ibsen
>>>>>>>> -----------------
>>>>>>>> FuseSource
>>>>>>>> Email: cibsen@fusesource.com
>>>>>>>> Web: http://fusesource.com
>>>>>>>> Twitter: davsclaus, fusenews
>>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> FuseSource
>>>>>> Email: cibsen@fusesource.com
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: davsclaus, fusenews
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: cibsen@fusesource.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus, fusenews
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: JMS and transaction
Posted by Hervé BARRAULT <he...@gmail.com>.
Thanks for your accurate answers.
I have seen messages groups but i have some messages which are out
potential groups.
So i have to deal with unordered messages. (or i should find a way to
have multiconsumer the main time and some time for some known messages
i should "downgrade" to only one consumer and then restart all
consumers but it will not work ^^).
Regards
Hervé
On 1/31/12, Claus Ibsen <cl...@gmail.com> wrote:
> On Tue, Jan 31, 2012 at 10:00 AM, Hervé BARRAULT
> <he...@gmail.com> wrote:
>> Thanks,
>> So, i should publish sequentially and can consume concurrently.
>
> Yeah, or public concurrently also. If ordering does not matter.
>
> Only if you need ordering of messages, and process concurrently you
> can use message groups
> http://activemq.apache.org/how-do-i-preserve-order-of-messages.html
> http://activemq.apache.org/how-do-message-groups-compare-to-selectors.html
> http://activemq.apache.org/message-groups.html
>
>
>>
>> As there is only direct component which is a synchronous call, I guess
>> a transaction can work across multiple route but in one camel context.
>>
>
> Yes that would work.
>
>> Am i wrong ?
>
> No.
>
>
>>
>>
>> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>>> On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
>>> <he...@gmail.com> wrote:
>>>> Hi,
>>>> thanks for the quick answer.
>>>>
>>>>> It does not support batching, not async TX, etc.
>>>>
>>>> But does it supports TX and concurrentConsumers ?
>>>>
>>>> I have to multiply the number of consumers as they are slower than the
>>>> producer.
>>>>
>>>
>>> Yes.
>>>
>>>
>>>>
>>>> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
>>>>> <he...@gmail.com> wrote:
>>>>>> Hi, thanks for confirmation.
>>>>>> So for publication, i should use a transactions with sequential
>>>>>> mechanism.
>>>>>>
>>>>>> I have seen also on activeMQ documentation :
>>>>>> http://activemq.apache.org/should-i-use-transactions.html :
>>>>>> Its also worth noting that if you are using persistent messaging, the
>>>>>> fastest way of using JMS is to actually use transactions and use
>>>>>> batching ...
>>>>>>
>>>>>> Is this mechanism working when using concurrentConsumer ?
>>>>>> Or should i choose between transaction and batching ?
>>>>>>
>>>>>
>>>>> The camel-jms component is baked on top of Spring JMS which is generic
>>>>> and limited in some areas.
>>>>> It does not support batching, not async TX, etc.
>>>>>
>>>>> Alot of people just use it as is, and its fast enough for their
>>>>> use-cases.
>>>>> I suggest to use that, and do some testing to see if its fast enough
>>>>> for
>>>>> you.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>> Thanks for answers
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Hervé
>>>>>>
>>>>>>
>>>>>> On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>>> Spring Transaction does not support using multiple threads. The
>>>>>>> transactional work should be done in the same thread, from spring TX
>>>>>>> manager point of view.
>>>>>>>
>>>>>>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
>>>>>>> <he...@gmail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I found in archive that parallel processing is not compatible with
>>>>>>>> transaction.
>>>>>>>>
>>>>>>>> Is it still relevant or is there a workaround ?
>>>>>>>>
>>>>>>>> Regards
>>>>>>>>
>>>>>>>> Hervé
>>>>>>>>
>>>>>>>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>> I have two question about a route, JMS and transactions.
>>>>>>>>>
>>>>>>>>> The use is : one request response Web service put message on n
>>>>>>>>> queues
>>>>>>>>> (using transaction ensure the message really put in all queues or
>>>>>>>>> no
>>>>>>>>> one).
>>>>>>>>>
>>>>>>>>> Does this route make sense (only "pseudo" route not all the stuff
>>>>>>>>> to
>>>>>>>>> manage transaction i guess) ?
>>>>>>>>>
>>>>>>>>> from("cxf:bean:myEndpoint").
>>>>>>>>> .wireTap("direct:tap")
>>>>>>>>> .process(myProcessor)
>>>>>>>>> transacted("PROPAGATION_REQUIRES_NEW")
>>>>>>>>> .multicast()
>>>>>>>>> .parallelProcessing()
>>>>>>>>> .recipientList(header("MY_HEADER"))
>>>>>>>>> .end()
>>>>>>>>> .process(myAnswerProcessor);
>>>>>>>>>
>>>>>>>>> from(direct:tap).process(myOptionalProcessor);
>>>>>>>>>
>>>>>>>>> If it could work, when is the transaction commit ?
>>>>>>>>>
>>>>>>>>> Thanks for answers.
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Hervé
>>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>> Claus Ibsen
>>>>>>> -----------------
>>>>>>> FuseSource
>>>>>>> Email: cibsen@fusesource.com
>>>>>>> Web: http://fusesource.com
>>>>>>> Twitter: davsclaus, fusenews
>>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> FuseSource
>>>>> Email: cibsen@fusesource.com
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus, fusenews
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> FuseSource
>>> Email: cibsen@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus, fusenews
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: JMS and transaction
Posted by Claus Ibsen <cl...@gmail.com>.
On Tue, Jan 31, 2012 at 10:00 AM, Hervé BARRAULT
<he...@gmail.com> wrote:
> Thanks,
> So, i should publish sequentially and can consume concurrently.
Yeah, or public concurrently also. If ordering does not matter.
Only if you need ordering of messages, and process concurrently you
can use message groups
http://activemq.apache.org/how-do-i-preserve-order-of-messages.html
http://activemq.apache.org/how-do-message-groups-compare-to-selectors.html
http://activemq.apache.org/message-groups.html
>
> As there is only direct component which is a synchronous call, I guess
> a transaction can work across multiple route but in one camel context.
>
Yes that would work.
> Am i wrong ?
No.
>
>
> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>> On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
>> <he...@gmail.com> wrote:
>>> Hi,
>>> thanks for the quick answer.
>>>
>>>> It does not support batching, not async TX, etc.
>>>
>>> But does it supports TX and concurrentConsumers ?
>>>
>>> I have to multiply the number of consumers as they are slower than the
>>> producer.
>>>
>>
>> Yes.
>>
>>
>>>
>>> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>> On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
>>>> <he...@gmail.com> wrote:
>>>>> Hi, thanks for confirmation.
>>>>> So for publication, i should use a transactions with sequential
>>>>> mechanism.
>>>>>
>>>>> I have seen also on activeMQ documentation :
>>>>> http://activemq.apache.org/should-i-use-transactions.html :
>>>>> Its also worth noting that if you are using persistent messaging, the
>>>>> fastest way of using JMS is to actually use transactions and use
>>>>> batching ...
>>>>>
>>>>> Is this mechanism working when using concurrentConsumer ?
>>>>> Or should i choose between transaction and batching ?
>>>>>
>>>>
>>>> The camel-jms component is baked on top of Spring JMS which is generic
>>>> and limited in some areas.
>>>> It does not support batching, not async TX, etc.
>>>>
>>>> Alot of people just use it as is, and its fast enough for their
>>>> use-cases.
>>>> I suggest to use that, and do some testing to see if its fast enough for
>>>> you.
>>>>
>>>>
>>>>
>>>>
>>>>> Thanks for answers
>>>>>
>>>>> Regards
>>>>>
>>>>> Hervé
>>>>>
>>>>>
>>>>> On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>>>> Spring Transaction does not support using multiple threads. The
>>>>>> transactional work should be done in the same thread, from spring TX
>>>>>> manager point of view.
>>>>>>
>>>>>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
>>>>>> <he...@gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I found in archive that parallel processing is not compatible with
>>>>>>> transaction.
>>>>>>>
>>>>>>> Is it still relevant or is there a workaround ?
>>>>>>>
>>>>>>> Regards
>>>>>>>
>>>>>>> Hervé
>>>>>>>
>>>>>>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>>>>>>> Hi,
>>>>>>>>
>>>>>>>> I have two question about a route, JMS and transactions.
>>>>>>>>
>>>>>>>> The use is : one request response Web service put message on n queues
>>>>>>>> (using transaction ensure the message really put in all queues or no
>>>>>>>> one).
>>>>>>>>
>>>>>>>> Does this route make sense (only "pseudo" route not all the stuff to
>>>>>>>> manage transaction i guess) ?
>>>>>>>>
>>>>>>>> from("cxf:bean:myEndpoint").
>>>>>>>> .wireTap("direct:tap")
>>>>>>>> .process(myProcessor)
>>>>>>>> transacted("PROPAGATION_REQUIRES_NEW")
>>>>>>>> .multicast()
>>>>>>>> .parallelProcessing()
>>>>>>>> .recipientList(header("MY_HEADER"))
>>>>>>>> .end()
>>>>>>>> .process(myAnswerProcessor);
>>>>>>>>
>>>>>>>> from(direct:tap).process(myOptionalProcessor);
>>>>>>>>
>>>>>>>> If it could work, when is the transaction commit ?
>>>>>>>>
>>>>>>>> Thanks for answers.
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Hervé
>>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Claus Ibsen
>>>>>> -----------------
>>>>>> FuseSource
>>>>>> Email: cibsen@fusesource.com
>>>>>> Web: http://fusesource.com
>>>>>> Twitter: davsclaus, fusenews
>>>>>> Blog: http://davsclaus.blogspot.com/
>>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: cibsen@fusesource.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus, fusenews
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: JMS and transaction
Posted by Hervé BARRAULT <he...@gmail.com>.
Thanks,
So, i should publish sequentially and can consume concurrently.
As there is only direct component which is a synchronous call, I guess
a transaction can work across multiple route but in one camel context.
Am i wrong ?
On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
> <he...@gmail.com> wrote:
>> Hi,
>> thanks for the quick answer.
>>
>>> It does not support batching, not async TX, etc.
>>
>> But does it supports TX and concurrentConsumers ?
>>
>> I have to multiply the number of consumers as they are slower than the
>> producer.
>>
>
> Yes.
>
>
>>
>> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>>> On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
>>> <he...@gmail.com> wrote:
>>>> Hi, thanks for confirmation.
>>>> So for publication, i should use a transactions with sequential
>>>> mechanism.
>>>>
>>>> I have seen also on activeMQ documentation :
>>>> http://activemq.apache.org/should-i-use-transactions.html :
>>>> Its also worth noting that if you are using persistent messaging, the
>>>> fastest way of using JMS is to actually use transactions and use
>>>> batching ...
>>>>
>>>> Is this mechanism working when using concurrentConsumer ?
>>>> Or should i choose between transaction and batching ?
>>>>
>>>
>>> The camel-jms component is baked on top of Spring JMS which is generic
>>> and limited in some areas.
>>> It does not support batching, not async TX, etc.
>>>
>>> Alot of people just use it as is, and its fast enough for their
>>> use-cases.
>>> I suggest to use that, and do some testing to see if its fast enough for
>>> you.
>>>
>>>
>>>
>>>
>>>> Thanks for answers
>>>>
>>>> Regards
>>>>
>>>> Hervé
>>>>
>>>>
>>>> On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>>> Spring Transaction does not support using multiple threads. The
>>>>> transactional work should be done in the same thread, from spring TX
>>>>> manager point of view.
>>>>>
>>>>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
>>>>> <he...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I found in archive that parallel processing is not compatible with
>>>>>> transaction.
>>>>>>
>>>>>> Is it still relevant or is there a workaround ?
>>>>>>
>>>>>> Regards
>>>>>>
>>>>>> Hervé
>>>>>>
>>>>>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>>>>>> Hi,
>>>>>>>
>>>>>>> I have two question about a route, JMS and transactions.
>>>>>>>
>>>>>>> The use is : one request response Web service put message on n queues
>>>>>>> (using transaction ensure the message really put in all queues or no
>>>>>>> one).
>>>>>>>
>>>>>>> Does this route make sense (only "pseudo" route not all the stuff to
>>>>>>> manage transaction i guess) ?
>>>>>>>
>>>>>>> from("cxf:bean:myEndpoint").
>>>>>>> .wireTap("direct:tap")
>>>>>>> .process(myProcessor)
>>>>>>> transacted("PROPAGATION_REQUIRES_NEW")
>>>>>>> .multicast()
>>>>>>> .parallelProcessing()
>>>>>>> .recipientList(header("MY_HEADER"))
>>>>>>> .end()
>>>>>>> .process(myAnswerProcessor);
>>>>>>>
>>>>>>> from(direct:tap).process(myOptionalProcessor);
>>>>>>>
>>>>>>> If it could work, when is the transaction commit ?
>>>>>>>
>>>>>>> Thanks for answers.
>>>>>>>
>>>>>>> Regards
>>>>>>> Hervé
>>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Claus Ibsen
>>>>> -----------------
>>>>> FuseSource
>>>>> Email: cibsen@fusesource.com
>>>>> Web: http://fusesource.com
>>>>> Twitter: davsclaus, fusenews
>>>>> Blog: http://davsclaus.blogspot.com/
>>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> FuseSource
>>> Email: cibsen@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus, fusenews
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: JMS and transaction
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
<he...@gmail.com> wrote:
> Hi,
> thanks for the quick answer.
>
>> It does not support batching, not async TX, etc.
>
> But does it supports TX and concurrentConsumers ?
>
> I have to multiply the number of consumers as they are slower than the producer.
>
Yes.
>
> On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
>> On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
>> <he...@gmail.com> wrote:
>>> Hi, thanks for confirmation.
>>> So for publication, i should use a transactions with sequential mechanism.
>>>
>>> I have seen also on activeMQ documentation :
>>> http://activemq.apache.org/should-i-use-transactions.html :
>>> Its also worth noting that if you are using persistent messaging, the
>>> fastest way of using JMS is to actually use transactions and use
>>> batching ...
>>>
>>> Is this mechanism working when using concurrentConsumer ?
>>> Or should i choose between transaction and batching ?
>>>
>>
>> The camel-jms component is baked on top of Spring JMS which is generic
>> and limited in some areas.
>> It does not support batching, not async TX, etc.
>>
>> Alot of people just use it as is, and its fast enough for their use-cases.
>> I suggest to use that, and do some testing to see if its fast enough for
>> you.
>>
>>
>>
>>
>>> Thanks for answers
>>>
>>> Regards
>>>
>>> Hervé
>>>
>>>
>>> On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
>>>> Spring Transaction does not support using multiple threads. The
>>>> transactional work should be done in the same thread, from spring TX
>>>> manager point of view.
>>>>
>>>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
>>>> <he...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I found in archive that parallel processing is not compatible with
>>>>> transaction.
>>>>>
>>>>> Is it still relevant or is there a workaround ?
>>>>>
>>>>> Regards
>>>>>
>>>>> Hervé
>>>>>
>>>>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I have two question about a route, JMS and transactions.
>>>>>>
>>>>>> The use is : one request response Web service put message on n queues
>>>>>> (using transaction ensure the message really put in all queues or no
>>>>>> one).
>>>>>>
>>>>>> Does this route make sense (only "pseudo" route not all the stuff to
>>>>>> manage transaction i guess) ?
>>>>>>
>>>>>> from("cxf:bean:myEndpoint").
>>>>>> .wireTap("direct:tap")
>>>>>> .process(myProcessor)
>>>>>> transacted("PROPAGATION_REQUIRES_NEW")
>>>>>> .multicast()
>>>>>> .parallelProcessing()
>>>>>> .recipientList(header("MY_HEADER"))
>>>>>> .end()
>>>>>> .process(myAnswerProcessor);
>>>>>>
>>>>>> from(direct:tap).process(myOptionalProcessor);
>>>>>>
>>>>>> If it could work, when is the transaction commit ?
>>>>>>
>>>>>> Thanks for answers.
>>>>>>
>>>>>> Regards
>>>>>> Hervé
>>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>> Claus Ibsen
>>>> -----------------
>>>> FuseSource
>>>> Email: cibsen@fusesource.com
>>>> Web: http://fusesource.com
>>>> Twitter: davsclaus, fusenews
>>>> Blog: http://davsclaus.blogspot.com/
>>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: JMS and transaction
Posted by Hervé BARRAULT <he...@gmail.com>.
Hi,
thanks for the quick answer.
> It does not support batching, not async TX, etc.
But does it supports TX and concurrentConsumers ?
I have to multiply the number of consumers as they are slower than the producer.
On 1/30/12, Claus Ibsen <cl...@gmail.com> wrote:
> On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
> <he...@gmail.com> wrote:
>> Hi, thanks for confirmation.
>> So for publication, i should use a transactions with sequential mechanism.
>>
>> I have seen also on activeMQ documentation :
>> http://activemq.apache.org/should-i-use-transactions.html :
>> Its also worth noting that if you are using persistent messaging, the
>> fastest way of using JMS is to actually use transactions and use
>> batching ...
>>
>> Is this mechanism working when using concurrentConsumer ?
>> Or should i choose between transaction and batching ?
>>
>
> The camel-jms component is baked on top of Spring JMS which is generic
> and limited in some areas.
> It does not support batching, not async TX, etc.
>
> Alot of people just use it as is, and its fast enough for their use-cases.
> I suggest to use that, and do some testing to see if its fast enough for
> you.
>
>
>
>
>> Thanks for answers
>>
>> Regards
>>
>> Hervé
>>
>>
>> On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
>>> Spring Transaction does not support using multiple threads. The
>>> transactional work should be done in the same thread, from spring TX
>>> manager point of view.
>>>
>>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
>>> <he...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I found in archive that parallel processing is not compatible with
>>>> transaction.
>>>>
>>>> Is it still relevant or is there a workaround ?
>>>>
>>>> Regards
>>>>
>>>> Hervé
>>>>
>>>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>>>> Hi,
>>>>>
>>>>> I have two question about a route, JMS and transactions.
>>>>>
>>>>> The use is : one request response Web service put message on n queues
>>>>> (using transaction ensure the message really put in all queues or no
>>>>> one).
>>>>>
>>>>> Does this route make sense (only "pseudo" route not all the stuff to
>>>>> manage transaction i guess) ?
>>>>>
>>>>> from("cxf:bean:myEndpoint").
>>>>> .wireTap("direct:tap")
>>>>> .process(myProcessor)
>>>>> transacted("PROPAGATION_REQUIRES_NEW")
>>>>> .multicast()
>>>>> .parallelProcessing()
>>>>> .recipientList(header("MY_HEADER"))
>>>>> .end()
>>>>> .process(myAnswerProcessor);
>>>>>
>>>>> from(direct:tap).process(myOptionalProcessor);
>>>>>
>>>>> If it could work, when is the transaction commit ?
>>>>>
>>>>> Thanks for answers.
>>>>>
>>>>> Regards
>>>>> Hervé
>>>>>
>>>
>>>
>>>
>>> --
>>> Claus Ibsen
>>> -----------------
>>> FuseSource
>>> Email: cibsen@fusesource.com
>>> Web: http://fusesource.com
>>> Twitter: davsclaus, fusenews
>>> Blog: http://davsclaus.blogspot.com/
>>> Author of Camel in Action: http://www.manning.com/ibsen/
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: JMS and transaction
Posted by Claus Ibsen <cl...@gmail.com>.
On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
<he...@gmail.com> wrote:
> Hi, thanks for confirmation.
> So for publication, i should use a transactions with sequential mechanism.
>
> I have seen also on activeMQ documentation :
> http://activemq.apache.org/should-i-use-transactions.html :
> Its also worth noting that if you are using persistent messaging, the
> fastest way of using JMS is to actually use transactions and use
> batching ...
>
> Is this mechanism working when using concurrentConsumer ?
> Or should i choose between transaction and batching ?
>
The camel-jms component is baked on top of Spring JMS which is generic
and limited in some areas.
It does not support batching, not async TX, etc.
Alot of people just use it as is, and its fast enough for their use-cases.
I suggest to use that, and do some testing to see if its fast enough for you.
> Thanks for answers
>
> Regards
>
> Hervé
>
>
> On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
>> Spring Transaction does not support using multiple threads. The
>> transactional work should be done in the same thread, from spring TX
>> manager point of view.
>>
>> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
>> <he...@gmail.com> wrote:
>>> Hi,
>>>
>>> I found in archive that parallel processing is not compatible with
>>> transaction.
>>>
>>> Is it still relevant or is there a workaround ?
>>>
>>> Regards
>>>
>>> Hervé
>>>
>>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>>> Hi,
>>>>
>>>> I have two question about a route, JMS and transactions.
>>>>
>>>> The use is : one request response Web service put message on n queues
>>>> (using transaction ensure the message really put in all queues or no
>>>> one).
>>>>
>>>> Does this route make sense (only "pseudo" route not all the stuff to
>>>> manage transaction i guess) ?
>>>>
>>>> from("cxf:bean:myEndpoint").
>>>> .wireTap("direct:tap")
>>>> .process(myProcessor)
>>>> transacted("PROPAGATION_REQUIRES_NEW")
>>>> .multicast()
>>>> .parallelProcessing()
>>>> .recipientList(header("MY_HEADER"))
>>>> .end()
>>>> .process(myAnswerProcessor);
>>>>
>>>> from(direct:tap).process(myOptionalProcessor);
>>>>
>>>> If it could work, when is the transaction commit ?
>>>>
>>>> Thanks for answers.
>>>>
>>>> Regards
>>>> Hervé
>>>>
>>
>>
>>
>> --
>> Claus Ibsen
>> -----------------
>> FuseSource
>> Email: cibsen@fusesource.com
>> Web: http://fusesource.com
>> Twitter: davsclaus, fusenews
>> Blog: http://davsclaus.blogspot.com/
>> Author of Camel in Action: http://www.manning.com/ibsen/
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: JMS and transaction
Posted by Hervé BARRAULT <he...@gmail.com>.
Hi, thanks for confirmation.
So for publication, i should use a transactions with sequential mechanism.
I have seen also on activeMQ documentation :
http://activemq.apache.org/should-i-use-transactions.html :
Its also worth noting that if you are using persistent messaging, the
fastest way of using JMS is to actually use transactions and use
batching ...
Is this mechanism working when using concurrentConsumer ?
Or should i choose between transaction and batching ?
Thanks for answers
Regards
Hervé
On 1/28/12, Claus Ibsen <cl...@gmail.com> wrote:
> Spring Transaction does not support using multiple threads. The
> transactional work should be done in the same thread, from spring TX
> manager point of view.
>
> On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
> <he...@gmail.com> wrote:
>> Hi,
>>
>> I found in archive that parallel processing is not compatible with
>> transaction.
>>
>> Is it still relevant or is there a workaround ?
>>
>> Regards
>>
>> Hervé
>>
>> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>>> Hi,
>>>
>>> I have two question about a route, JMS and transactions.
>>>
>>> The use is : one request response Web service put message on n queues
>>> (using transaction ensure the message really put in all queues or no
>>> one).
>>>
>>> Does this route make sense (only "pseudo" route not all the stuff to
>>> manage transaction i guess) ?
>>>
>>> from("cxf:bean:myEndpoint").
>>> .wireTap("direct:tap")
>>> .process(myProcessor)
>>> transacted("PROPAGATION_REQUIRES_NEW")
>>> .multicast()
>>> .parallelProcessing()
>>> .recipientList(header("MY_HEADER"))
>>> .end()
>>> .process(myAnswerProcessor);
>>>
>>> from(direct:tap).process(myOptionalProcessor);
>>>
>>> If it could work, when is the transaction commit ?
>>>
>>> Thanks for answers.
>>>
>>> Regards
>>> Hervé
>>>
>
>
>
> --
> Claus Ibsen
> -----------------
> FuseSource
> Email: cibsen@fusesource.com
> Web: http://fusesource.com
> Twitter: davsclaus, fusenews
> Blog: http://davsclaus.blogspot.com/
> Author of Camel in Action: http://www.manning.com/ibsen/
>
Re: JMS and transaction
Posted by Claus Ibsen <cl...@gmail.com>.
Spring Transaction does not support using multiple threads. The
transactional work should be done in the same thread, from spring TX
manager point of view.
On Fri, Jan 27, 2012 at 5:29 PM, Hervé BARRAULT
<he...@gmail.com> wrote:
> Hi,
>
> I found in archive that parallel processing is not compatible with transaction.
>
> Is it still relevant or is there a workaround ?
>
> Regards
>
> Hervé
>
> On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
>> Hi,
>>
>> I have two question about a route, JMS and transactions.
>>
>> The use is : one request response Web service put message on n queues
>> (using transaction ensure the message really put in all queues or no
>> one).
>>
>> Does this route make sense (only "pseudo" route not all the stuff to
>> manage transaction i guess) ?
>>
>> from("cxf:bean:myEndpoint").
>> .wireTap("direct:tap")
>> .process(myProcessor)
>> transacted("PROPAGATION_REQUIRES_NEW")
>> .multicast()
>> .parallelProcessing()
>> .recipientList(header("MY_HEADER"))
>> .end()
>> .process(myAnswerProcessor);
>>
>> from(direct:tap).process(myOptionalProcessor);
>>
>> If it could work, when is the transaction commit ?
>>
>> Thanks for answers.
>>
>> Regards
>> Hervé
>>
--
Claus Ibsen
-----------------
FuseSource
Email: cibsen@fusesource.com
Web: http://fusesource.com
Twitter: davsclaus, fusenews
Blog: http://davsclaus.blogspot.com/
Author of Camel in Action: http://www.manning.com/ibsen/
Re: JMS and transaction
Posted by Hervé BARRAULT <he...@gmail.com>.
Hi,
I found in archive that parallel processing is not compatible with transaction.
Is it still relevant or is there a workaround ?
Regards
Hervé
On 1/27/12, Hervé BARRAULT <he...@gmail.com> wrote:
> Hi,
>
> I have two question about a route, JMS and transactions.
>
> The use is : one request response Web service put message on n queues
> (using transaction ensure the message really put in all queues or no
> one).
>
> Does this route make sense (only "pseudo" route not all the stuff to
> manage transaction i guess) ?
>
> from("cxf:bean:myEndpoint").
> .wireTap("direct:tap")
> .process(myProcessor)
> transacted("PROPAGATION_REQUIRES_NEW")
> .multicast()
> .parallelProcessing()
> .recipientList(header("MY_HEADER"))
> .end()
> .process(myAnswerProcessor);
>
> from(direct:tap).process(myOptionalProcessor);
>
> If it could work, when is the transaction commit ?
>
> Thanks for answers.
>
> Regards
> Hervé
>