Mailing-List: contact users-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@camel.apache.org
Received-SPF: pass (nike.apache.org: domain of roman.kalukiewicz@gmail.com
 designates 209.85.218.159 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:date:message-id:subject:from:to:content-type;
        b=fmcrFo8rbw3QnlEW6k2Ez4bElb6Vl8Fmd02+Zr6P/4/8f93NbrOFccR1HQpG0u21cj
         jLStlgOh6FRNolVv+Z1s03ZbqPF0m/JSB+SpVyIMbwS3ux8C8fOnyRjR28FpHBjt8axV
         iVwDlkexLBucDbC6yjhPiN5Zo6SIIYBh6O0SQ=
MIME-Version: 1.0
Date: Tue, 7 Apr 2009 18:29:53 +0200
Message-ID: <f1c427510904070929u56596a3kaa3d08e245ca43d3@mail.gmail.com>
Subject: Camel transactions with in-out JMS
From: Roman Kalukiewicz <roman.kalukiewicz@gmail.com>
To: camel-user@activemq.apache.org
Content-Type: multipart/alternative; boundary=001636c5a7235ce3100466f986c4

--001636c5a7235ce3100466f986c4
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

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

--001636c5a7235ce3100466f986c4--