Mailing-List: contact dev-help@camel.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@camel.apache.org
Message-ID: <6007573.611274105944383.JavaMail.jira@thor>
Date: Mon, 17 May 2010 10:19:04 -0400 (EDT)
From: "Sergio Bossa (JIRA)" <jira@apache.org>
To: camel-dev@activemq.apache.org
Subject: [jira] Created: (CAMEL-2729) Enable transaction propagation for
 SEDA component
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit

Enable transaction propagation for SEDA component
-------------------------------------------------

                 Key: CAMEL-2729
                 URL: https://issues.apache.org/activemq/browse/CAMEL-2729
             Project: Apache Camel
          Issue Type: Improvement
    Affects Versions: 2.2.0
            Reporter: Sergio Bossa
         Attachments: seda-camel.zip

I was recently working on a pure SEDA prototype based on Camel and ActiveMQ, and the biggest problem I had was the lack of transaction propagation among stages/threads, due to the Spring transaction-per-thread model which Camel relies on.
Hence, it is currently impossible to commit/rollback transactions from a different stage than the one that initiated it.

So, I developed a patch to org.apache.camel.component.jms.JmsConfiguration class in order to use a custom org.springframework.jms.listener.AbstractMessageListenerContainer which enables external transaction management.
Then, I developed a Camel bean component to bind and propagate transactional resources among threads, and manually commit/rollback transactions.
I'm attaching a sample project containing and showcasing all this stuff: it reads from an ActiveMQ queue, does dummy processing, and puts on another queue.
In order to run:
$> mvn test
In order to run with an injected fault and do rollback:
$> mvn test -Pfault-test
WARN: requires a local ActiveMQ broker at tcp://localhost:61616

I'd like to gain some feedback and eventually talk about including such a features into Camel code base, which would require to:
1) Patch JmsConfiguration in order to allow injection of external AbstractMessageListenerContainer implementations.
2) Patch JmsConfiguration in order to avoid forcing to set the TransactionManager.
3) Somewhat enrich the Seda component to natively support transaction propagation.

Feel free to ask any question, and thanks for listening!

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.