camel-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruce Snyder" <>
Subject Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...
Date Wed, 27 Aug 2008 13:56:40 GMT
On Wed, Aug 27, 2008 at 6:57 AM, James Strachan
<> wrote:
> 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
> everything.
> So the route
> <camelContext xmlns="">
>  <route>
>    <from uri="activemq:A"/>
>    <to uri="activemq:B"/>
>    <to uri="activemq:C"/>
>    <to uri="activemq:D"/>
>  </route>
> </camelContext>
> 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
> JmsTransactionManager
> 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).
> Thoughts?

I like the idea of changing the default because so many folks need
transactions and then struggle with the configuration for it. As long
as it's documented that this is the new default, I don't think it will
trip up too many people. In fact, I think it would stand to benefit a
lot of people, especially new users. It might also be worth creating
additional examples that demonstrate the use of Atomikos, Bitronix and
maybe Jboss transaction managers, too.

perl -e 'print unpack("u30","D0G)U8V4\@4VYY9&5R\"F)R=6-E+G-N>61E<D\!G;6%I;\"YC;VT*"

Apache ActiveMQ -
Apache Camel -
Apache ServiceMix -


View raw message