camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sicker <>
Subject Re: JMS Batch consumption
Date Sat, 09 Aug 2014 01:18:28 GMT
I, too, have found the transaction support to be a bit inflexible.
Honestly, I'd probably implement such a thing using EJB, JMS, JPA (or JDBC,
doesn't really matter), and JTA. Though I'm not super clear on the
semantics of using a global transaction with nested local transactions.

Anyway, perhaps you could take advantage of Spring's transaction support?
That's what Camel uses to provided transaction support, and there's a bunch
more things available from the full Spring API.

Hope this helps!

On 8 August 2014 04:37, Arnaud Deprez <> wrote:

> Hi folks !
> I'd like to write a camel route that consumes a group of messages from a
> queue to persist it in a database in a single transaction and of course I
> can't loose any message.
> Basically, I was hoping it will work as expected by using a transacted
> route with an aggregation strategy in memory, then split the aggregation
> result, do a bit of business process and then store it in the database.
> But it doesn't work. It seems that every message that goes to the
> aggregator is commited/acknowledged just after the aggregator. So if
> something goes wrong, I loose my message :-(.
> I also read in chapter8's camel book that if we want to use a aggregation
> strategy in a transactional way, we can use a persistent repository and use
> one transaction from the queue to the aggregation repository and then
> another transaction from the transaction repository to the database.
> But I really don't like this solution. Why should I need another another
> repository before persist my message in a database ?
> I also read that the aggregator can be used with a batch consumer
> But there is none for JMS and
> I don't know if it will solve this problem.
> According to me, it seems to be a design issue but I'm not sure and I'd
> like your point of view about this ? If you have a workaround or another
> solution that can suit to me, please share ! :-)
> Arnaud Deprez

Matt Sicker <>

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message