camel-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From tourist604 <>
Subject Transactions in camel: more questions (1.4.0)
Date Sun, 10 Aug 2008 23:00:34 GMT


I have been trying to figure out how to use transactions in camel.

My original requirements are simple:
While in transaction, do:
1. Consume a JMS message
2. Process it and route it to an http endpoint
3. If http resets connection or returns with invalid status,
4. Retry the message using DeadLetterChannel facilities and exception based
handling and re-route, if all fails, elsewhere.

While trying to figure out how to use transaction consumption of JMS
messages in camel, I have found this post in the forum:

This post led me to believe that I need to add this to my route IN ADDITION
to specifying the JMSComponent as transactional in the spring context:

--- spring context snippet: ---

	<bean id="activemq"
		<property name="connectionFactory">
			<ref bean="jmsConnectionFactory" />
		<property name="transactionManager">
			<ref bean="jmsTransactionManager" />
		<property name="transacted">

--- end of spring contxt snippet: ---

--- route definition snippet: ---
 Policy required = new SpringTransactionPolicy(bean(
                        TransactionTemplate.class, "PROPAGATION_REQUIRED")); 
 from( "activemq:myqueue" ).policy( required )...

--- end of route definition snippet ----

The configuration above fails in one major way: it doesn't allow me to use
the DeadLetterChannel to handle errors.

After spending a few days battling with this configuration, I have come to
the following conclusions:

1. Attaching a "PROPAGATION_REQUIRED" policy to the route does not initiate
the transaction. The transaction is initiated by JmsComponent; in fact, it's
initiated by Spring itself via the Message-Driven POJO support.
2. Attaching this policy will cause a flag to be set on the exchange which
will make DeadLetterChannel skip altogether, thereby foregoing its (in my
opinion great!!!) mechanism of discriminately handling different exceptions
in different ways and re-routing the message elsewhere. The errorHandler
cannot be placed after the transactional policy in the route; it will always
be placed before by the route "start" code.
3. On error, org.apache.camel.spring.spi.TransactionInterceptor which is
injected by adding the PROPAGATION_REQUIRED policy returns with 3 conditions
which may be interpreted as rolling back the transaction:

line: 128 if (rce != null) {
                    redeliveryData.previousRollback = true;
                    if (activeTx) {
                        LOG.debug("Transaction rollback");
                    throw rce;

a) status.setRollbackOnly(): I tried skipping this flag, and transaction
still rolled back so it appears to be ineffectual
b) "throw rce" will cause the TransactionTemplate to perform a rollback
c) the original exchange may contain an exception which will cause the
message listener to re-throw it.

(the above 3 things may be confusing to anyone trying to debug the
transactional handling)

4. NOT ADDING the policy to the route still makes the route operate within
the transaction initated by the JmsComponent and spring **AND**
DeadLetterChannel is happily available to handle your retries and re-routing
WITHIN the original transaction.
5. If I **send** (while re-routing) a message within the same route using
the same JmsComponent, configured with the same transaction manager, the
default "PROPAGATION_REQUIRED" propagation behaviour in spring's
TransactionTemplate will cause this operation to be enlisted within the
original transaction initiated by the JMS consumer thus rendering the whole
route to operate within the same transaction (here we are using the same
transactional data sources, i.e. the same activemq broker, so no distributed

Can anyone confirm the validity of these assumptions? 

I would greatly appreciate it as the transactional behaviour in camel is a
critical aspect of a our camel-based integration solution.

View this message in context:
Sent from the Camel - Users mailing list archive at

View raw message