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 <claus.ib...@gmail.com> wrote: > On Mon, Jan 30, 2012 at 11:05 AM, Hervé BARRAULT > <herve.barra...@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 <claus.ib...@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 >>> <herve.barra...@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 <herve.barra...@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: cib...@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: cib...@fusesource.com > Web: http://fusesource.com > Twitter: davsclaus, fusenews > Blog: http://davsclaus.blogspot.com/ > Author of Camel in Action: http://www.manning.com/ibsen/ >