On Mon, Jan 30, 2012 at 3:41 PM, Hervé BARRAULT <herve.barra...@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 <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/ >> -- 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/
