camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Roman Kalukiewicz <>
Subject Camel transactions with in-out JMS
Date Tue, 07 Apr 2009 16:29:53 GMT
Hello Camel Riders!

Let me show an example of a problem I'm working on:


(this is not created with IDE, so might be worng but I hope you get the

If this flow works as in-out and is transactional then it will not work as
messages are not sent to "jms:splitted" before transaction from
"jms:in-queue" is commited and it is not commited before response from
splitter is not sent back. It just hungs up.

One solution is to make "jms:splited" non-transactional, but then we agree,
that we can have duplicates on "jms:splited" queue (we sent few messages
already, something fails, transaction is rolled back, we consume it once
again and we resend parts, that were already sent to "splited").

I believe the proper behaviour would be to have two separate transactions
* first transaction covers receive operation from in-queue, split and
sending requests to jms:splited and is commited when all requests to
'jms:splitted' are sent
* second transaction covers all receive operations  from jms:splited,
aggregation and sending a response to jms:in-queue. Is commited when final
response is sent.

This way we are 100% transactional and nothing can be lost and nothing can
be duplicated.

Right now I don't believe it is possible in camel. Moreover I cannot find a
way to clearly abstract the problem so it can be unified over other
components (not only JMS).
I believe the problem is, that we try to model JMS (that is by its nature
in-only especially when it comes to transactions) as in-out. If we model it
as two separate in-only flows with splitter and agregator it would work
fine, but then we don't have a way to listen only for our responses and to
receive all responses in the same transaction.

Maybe some of you have any thoughts on this problem?

Roman Kalukiewicz

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