Actually I would like a more flexible solution, like using some kind of a
strategy or maybe a route policy or something to trigger the commit (I'm
not aware of all mechanisms existing in Camel that might be suiting here).
My use case is not completely defined yet, but something like this:
1. Assume a persistent queue Q with a number of messages on it. Each
message has a header "BatchId" on it.
2. Start the route (JMS consumer on queue Q) at a scheduled time (there are
existing mechanisms to do this AFAIK) or manually (JMX).
3. Use the "BatchId" header on the first consumed message as a JMS selector
query for remaining messages to be consumed in the current
transaction/batch.
4. Commit the transaction when <some condition> is met.
(4) is kind of the tricky part in my case -- I haven't been able to decide
what that condition should be. It should be when there are no more messages
on the queue with the current BatchId, but that would be somewhat difficult
to match. The condition couldn't be a given number of messages, as there
should be no assumption on the number of messages in the batch and we would
risk the transaction staying open forever. Maybe a control message on the
same queue or another queue or endpoint, a timeout value on the JMS receive
call or something. Ideally the component should leave this condition to
some strategy that could be injected for maximum flexibility. Anyway I hope
you see my requirement a little clearer?
Cheers,
Thomas
2012/8/7 Scott England-Sullivan <sully6...@gmail.com>
> Hi Thomas,
>
> It sounds like you are looking for something like the following:
>
> from("sjms:consumer?transacted=true&batch=100")
> .processor("do stuff")
> to("file:output");
>
> Such that 100 messages would be consumed, processed and filed followed by
> the session either being committed or rolled back based on the success or
> fail of all 100 exchanges.
>
> Sound about right?
>
>
> On Tue, Aug 7, 2012 at 11:49 AM, Thomas Johansen <thxm...@gmail.com>
> wrote:
>
> > I'm not sure what this implies, Scott.
> >
> > My use case is to have a transaction started on a first exchange, and
> then
> > have X exhanges on the same transaction. It should first be committed
> when
> > some external event happens, like a control message is seen (possibly
> from
> > a separate control queue), after X number of messages or something. I'm
> > sure Camel provides some options for mechanisms to use here? In my case I
> > need to aggregate X records into a single file.
> >
> > Thomas
> >
> >
> > Den 7. aug. 2012 kl. 14:50 skrev Scott England-Sullivan <
> > sully6...@gmail.com>:
> >
> > > I will take a look at it tonight. Plan is to add batch support by
> having
> > > the Producer and Consumer endpoints support a List of Messages. Once
> in
> > > place TX would be automatically supported as it is called as a
> > > Synchronization upon completion of the Exchange.
> > >
> > > Thoughts?
> > >
> > > On Tue, Aug 7, 2012 at 6:21 AM, Christian Müller <
> > > christian.muel...@gmail.com> wrote:
> > >
> > >> +1
> > >> Would like to see this feature too...
> > >>
> > >> Sent from a mobile device
> > >> Am 07.08.2012 10:49 schrieb "Thomas Johansen" <thxm...@gmail.com>:
> > >>
> > >>> Hi,
> > >>>
> > >>> As I understand the JMSComponent/ActiveMQComponent cannot support
> > batched
> > >>> transactions due to the use of Spring's DMLC. With this new
> > SJMSComponent
> > >>> there should be possibilities to implement this, I guess?
> > >>>
> > >>> BR,
> > >>> Thomas
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > --
> > > Scott England-Sullivan
> > > ----------------------------------
> > > FuseSource
> > > Web: http://www.fusesource.com
> > > Blog: http://sully6768.blogspot.com
> > > Twitter: sully6768
> >
>
>
>
> --
> --
> Scott England-Sullivan
> ----------------------------------
> FuseSource
> Web: http://www.fusesource.com
> Blog: http://sully6768.blogspot.com
> Twitter: sully6768
>
