FAQ
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é

Search Discussions

  • Hervé BARRAULT at Jan 27, 2012 at 4:29 pm
    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 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 at Jan 28, 2012 at 9:19 am
    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
    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 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/
  • Hervé BARRAULT at Jan 30, 2012 at 10:05 am
    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 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
    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 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 at Jan 30, 2012 at 1:32 pm

    On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT 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 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
    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 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/
  • Hervé BARRAULT at Jan 30, 2012 at 2:41 pm
    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 wrote:
    On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
    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 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
    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 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 at Jan 30, 2012 at 2:47 pm

    On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT 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 wrote:
    On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
    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 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
    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 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/
  • Hervé BARRAULT at Jan 31, 2012 at 9:01 am
    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 wrote:
    On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
    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 wrote:
    On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
    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 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
    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 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 at Jan 31, 2012 at 9:31 am

    On Tue, Jan 31, 2012 at 10:00 AM, Hervé BARRAULT 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 wrote:
    On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
    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 wrote:
    On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
    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 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
    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 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/
  • Hervé BARRAULT at Jan 31, 2012 at 10:01 am
    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 wrote:
    On Tue, Jan 31, 2012 at 10:00 AM, Hervé BARRAULT
    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 wrote:
    On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
    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 wrote:
    On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
    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 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
    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 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 at Jan 31, 2012 at 11:16 am
    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
    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 wrote:
    On Tue, Jan 31, 2012 at 10:00 AM, Hervé BARRAULT
    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 wrote:
    On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT
    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 wrote:
    On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT
    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 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
    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 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/

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupusers @
categoriescamel
postedJan 27, '12 at 1:28p
activeJan 31, '12 at 11:16a
posts11
users2
websitecamel.apache.org

2 users in discussion

Hervé BARRAULT: 6 posts Claus Ibsen: 5 posts

People

Translate

site design / logo © 2022 Grokbase