camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "James Strachan" <>
Subject switching JMS to use transacted mode by default and to auto-default the TrasactionManager...
Date Wed, 27 Aug 2008 12:57:45 GMT
I've been pondering about the use of JMS and transactions. We've
always tried to follow the convention over configuration maxim with
Camel; so things should do what you expect without having to configure

So the route

<camelContext xmlns="">
    <from uri="activemq:A"/>
    <to uri="activemq:B"/>
    <to uri="activemq:C"/>
    <to uri="activemq:D"/>

should route from the ActiveMQ queue A to queues B, C, D without any
other configuration if you want to use the defaults (such as the
message broker is on localhost on the usual port of 61616.

However this doesn't use JMS transactions and spring declarative
transactions by default; you've gotta configure the ActiveMQ component
with transacted=true along with a transaction manager etc.

So I'm wondering for 1.5.0 of Camel if we made 2 subtle changes...

* JMS component defaults to transacted by default
* JMS component has a lazyCreateTransactionManager flag which defaults to true
* if transacted and lazyCreateTransactionManager and there is no
transactionManager configured, default to using the Spring

Then we'd be using spring transactions by default without the user
having to write reams of spring.xml stuff and it'd generally do the
right thing. Folks not keen on the 'magic' of convention over
configuration could disable this option - as well as using JMS in a
non-transacted mode as well.

I guess the only real change folks would notice is that things would
be transacted by default unless explicitly configured - which might
trip some folks up at first.

Part of the motivation for this is that its so easy to mess up the
configuration of the Spring transaction manager when using Camel; as
the Spring JMS transaction manager needs the exact connectionFactory
used as a property; so you've gotta create the JMS component, a JMS
connection factory and a JMS transaction manager as 3 separate beans
and wire them together just so - which becomes even more harder and
error prone if you add a JMS pool proxy or a User/Password proxy
connection factory and so forth.

i.e. I wanted to make it really simple to do the common stuff.

I guess we might decide to back off from making the JMS component be
transacted by default - but could still use the other changes (so if
transacted, we do the right thing).



Open Source Integration

View raw message