Hello Camel Riders!
Let me show an example of a problem I'm working on:
from("jms:in-queue").split(xpath("/foos/*"),
myAggregator).parallelProcessing().to("jms:splited");
(this is not created with IDE, so might be worng but I hope you get the
idea).
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
here:
* 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?
Cheers
Roman Kalukiewicz
