switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

jstrachan
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="http://activemq.apache.org/camel/schema/spring">
  <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?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

RE: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

Claus Ibsen
Hi

Just a side note:
The username/password has been asked several times on the user forum. Maybe we can do some smart thing there as well? Or at least document in the JMS wiki how to set it up, or point in right direction.

Will get back to "any thoughts" later, but I gotta fight with the CAPS now ;)


Med venlig hilsen
 
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

-----Original Message-----
From: James Strachan [mailto:[hidden email]]
Sent: 27. august 2008 14:58
To: [hidden email]
Subject: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

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="http://activemq.apache.org/camel/schema/spring">
  <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?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

jstrachan
2008/8/27 Claus Ibsen <[hidden email]>:
> Hi
>
> Just a side note:
> The username/password has been asked several times on the user forum. Maybe we can do some smart thing there as well? Or at least document in the JMS wiki how to set it up, or point in right direction.

Yeah - I was thinking the JMS component could have username/property
attributes which if specified wrap the underlying JMS
ConnectionFactory in the Spring helper class

> Will get back to "any thoughts" later, but I gotta fight with the CAPS now ;)

good luck! :)

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

Bruce Snyder
In reply to this post by jstrachan
On Wed, Aug 27, 2008 at 6:57 AM, James Strachan
<[hidden email]> 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="http://activemq.apache.org/camel/schema/spring">
>  <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.

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

Apache ActiveMQ - http://activemq.org/
Apache Camel - http://activemq.org/camel/
Apache ServiceMix - http://servicemix.org/

Blog: http://bruceblog.org/
Reply | Threaded
Open this post in threaded view
|

RE: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

Claus Ibsen
In reply to this post by jstrachan
Short answer:
+1

We also have a ticket about a better default configuration for the DeadLetterChannel. As now it does 5 retries with 1 sec apart. Not the best "conv over conf". So maybe something on a sidenote to consider fixing for 1.5 now that we do this JMS transacted stuff out-of-the-box ;)


Med venlig hilsen
 
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk
-----Original Message-----
From: James Strachan [mailto:[hidden email]]
Sent: 27. august 2008 14:58
To: [hidden email]
Subject: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

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="http://activemq.apache.org/camel/schema/spring">
  <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?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

jstrachan
2008/8/28 Claus Ibsen <[hidden email]>:
> Short answer:
> +1
>
> We also have a ticket about a better default configuration for the DeadLetterChannel. As now it does 5 retries with 1 sec apart. Not the best "conv over conf". So maybe something on a sidenote to consider fixing for 1.5 now that we do this JMS transacted stuff out-of-the-box ;)

Yeah thats a great point. Maybe we should make the change to
transacted by default a 2.0 thing; as its a big change. For 2.0 we
could overhaul the default error handlers and transaction modes to
make stuff transacted by default - and use a transacted error handler
by default rather than the DeadLetterChannel - which doesn't work too
well with JDBC/JMS or other transacted endpoints

e.g. for 1.5 make it easy to enable transacted JMS with a simple
"transacted=true" property on the endpoint/component and then
auto-create the transaction manager by default for JMS (maybe
JPA/Hibernate too?) - then in 2.0 we switch the defaults to be
transacted out of the box with matching error handlers?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

RE: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

Claus Ibsen
+1 for the 1.5/2.0 idea

And maybe for 2.0 we get the "transactional files" also with the apache commons project ;)


Med venlig hilsen
 
Claus Ibsen
......................................
Silverbullet
Skovsgårdsvænget 21
8362 Hørning
Tlf. +45 2962 7576
Web: www.silverbullet.dk

-----Original Message-----
From: James Strachan [mailto:[hidden email]]
Sent: 28. august 2008 13:31
To: [hidden email]
Subject: Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

2008/8/28 Claus Ibsen <[hidden email]>:
> Short answer:
> +1
>
> We also have a ticket about a better default configuration for the DeadLetterChannel. As now it does 5 retries with 1 sec apart. Not the best "conv over conf". So maybe something on a sidenote to consider fixing for 1.5 now that we do this JMS transacted stuff out-of-the-box ;)

Yeah thats a great point. Maybe we should make the change to
transacted by default a 2.0 thing; as its a big change. For 2.0 we
could overhaul the default error handlers and transaction modes to
make stuff transacted by default - and use a transacted error handler
by default rather than the DeadLetterChannel - which doesn't work too
well with JDBC/JMS or other transacted endpoints

e.g. for 1.5 make it easy to enable transacted JMS with a simple
"transacted=true" property on the endpoint/component and then
auto-create the transaction manager by default for JMS (maybe
JPA/Hibernate too?) - then in 2.0 we switch the defaults to be
transacted out of the box with matching error handlers?

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

jstrachan
2008/8/28 Claus Ibsen <[hidden email]>:
> +1 for the 1.5/2.0 idea
>
> And maybe for 2.0 we get the "transactional files" also with the apache commons project ;)

Agreed! :)

We might need a Spring FileTransactionManager too :)

--
James
-------
http://macstrac.blogspot.com/

Open Source Integration
http://open.iona.com
Reply | Threaded
Open this post in threaded view
|

Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...

Jon Anstey
In reply to this post by Claus Ibsen
Claus Ibsen wrote:
> +1 for the 1.5/2.0 idea
>
> And maybe for 2.0 we get the "transactional files" also with the apache commons project ;)
>  

Already on my TODO list :)

>
> Med venlig hilsen
>  
> Claus Ibsen
> ......................................
> Silverbullet
> Skovsgårdsvænget 21
> 8362 Hørning
> Tlf. +45 2962 7576
> Web: www.silverbullet.dk
>
> -----Original Message-----
> From: James Strachan [mailto:[hidden email]]
> Sent: 28. august 2008 13:31
> To: [hidden email]
> Subject: Re: switching JMS to use transacted mode by default and to auto-default the TrasactionManager...
>
> 2008/8/28 Claus Ibsen <[hidden email]>:
>  
>> Short answer:
>> +1
>>
>> We also have a ticket about a better default configuration for the DeadLetterChannel. As now it does 5 retries with 1 sec apart. Not the best "conv over conf". So maybe something on a sidenote to consider fixing for 1.5 now that we do this JMS transacted stuff out-of-the-box ;)
>>    
>
> Yeah thats a great point. Maybe we should make the change to
> transacted by default a 2.0 thing; as its a big change. For 2.0 we
> could overhaul the default error handlers and transaction modes to
> make stuff transacted by default - and use a transacted error handler
> by default rather than the DeadLetterChannel - which doesn't work too
> well with JDBC/JMS or other transacted endpoints
>
> e.g. for 1.5 make it easy to enable transacted JMS with a simple
> "transacted=true" property on the endpoint/component and then
> auto-create the transaction manager by default for JMS (maybe
> JPA/Hibernate too?) - then in 2.0 we switch the defaults to be
> transacted out of the box with matching error handlers?
>
>