You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@camel.apache.org by chrajanirao <ra...@gmail.com> on 2009/01/28 01:06:03 UTC
JmsComponent issue with spring's JmsTransactionManager is used
Hi,
It seems to me that Spring's DMLC implementation has a flaw/bug when
JmsTransactionManager and CACHE_SESSION is used. It seems, spring is
creating a session upfront once as we have cache session and a new session
for every message in JmsTransactionManager. The cached session is being used
for receiving. Hence if you don't specify sessionTransacted=true but supply
the TX manager, the non-transacted cached session is used for consuming
messages. This is a serious problem.
Although this is a spring issue, I wanted to bring it up here as Camel is
enforcing that you supply a Tx manager when sessionTransacted=true and it
degrades performance by creating a new session evetytime and not even use it
consume messages.
If someone from Camel team can confirm this behavior, I can create an issue
for Spring team to fix the DMLC implementation to use the cached session
when exists under JmsTransactionManager similar to using Shared Connection.
Thanks,
Rajani.
--
View this message in context: http://www.nabble.com/JmsComponent-issue-with-spring%27s-JmsTransactionManager-is-used-tp21697364s22882p21697364.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: JmsComponent issue with spring's JmsTransactionManager is used
Posted by Guillaume Nodet <gn...@gmail.com>.
Actually, I've hit another problem with DMLC when using XA transactions.
It happens that the session exposed is not the one that is enlisted in
the transaction :-(
ANyway, for you problem, have you tried using CACHE_NONE and a pooled
connection factory ?
On Wed, Jan 28, 2009 at 01:06, chrajanirao <ra...@gmail.com> wrote:
>
> Hi,
>
> It seems to me that Spring's DMLC implementation has a flaw/bug when
> JmsTransactionManager and CACHE_SESSION is used. It seems, spring is
> creating a session upfront once as we have cache session and a new session
> for every message in JmsTransactionManager. The cached session is being used
> for receiving. Hence if you don't specify sessionTransacted=true but supply
> the TX manager, the non-transacted cached session is used for consuming
> messages. This is a serious problem.
>
> Although this is a spring issue, I wanted to bring it up here as Camel is
> enforcing that you supply a Tx manager when sessionTransacted=true and it
> degrades performance by creating a new session evetytime and not even use it
> consume messages.
>
> If someone from Camel team can confirm this behavior, I can create an issue
> for Spring team to fix the DMLC implementation to use the cached session
> when exists under JmsTransactionManager similar to using Shared Connection.
>
> Thanks,
> Rajani.
> --
> View this message in context: http://www.nabble.com/JmsComponent-issue-with-spring%27s-JmsTransactionManager-is-used-tp21697364s22882p21697364.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: JmsComponent issue with spring's JmsTransactionManager is used
Posted by James Strachan <ja...@gmail.com>.
2009/1/30 chrajanirao <ra...@gmail.com>:
>
> I just realized that we need to use
> "org.springframework.jms.connection.CachingConnectionFactory". As of spring
> 2.5.6, this supports caching of connection/sessions/consumers/producers and
> is strongly recommended to use with JmsTransactionManager!
Lets do it :)
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/
Re: JmsComponent issue with spring's JmsTransactionManager is used
Posted by Guillaume Nodet <gn...@gmail.com>.
FTR, it does not really cache consumers. Caching consumers is
problematic as it can lead to messages being kinda lost if they are
unconsumed and the consumer is not closed.
On Fri, Jan 30, 2009 at 05:53, chrajanirao <ra...@gmail.com> wrote:
>
> I just realized that we need to use
> "org.springframework.jms.connection.CachingConnectionFactory". As of spring
> 2.5.6, this supports caching of connection/sessions/consumers/producers and
> is strongly recommended to use with JmsTransactionManager!
> --
> View this message in context: http://www.nabble.com/JmsComponent-issue-with-spring%27s-JmsTransactionManager-is-used-tp21697364s22882p21741460.html
> Sent from the Camel - Users mailing list archive at Nabble.com.
>
>
--
Cheers,
Guillaume Nodet
------------------------
Blog: http://gnodet.blogspot.com/
------------------------
Open Source SOA
http://fusesource.com
Re: JmsComponent issue with spring's JmsTransactionManager is used
Posted by chrajanirao <ra...@gmail.com>.
I just realized that we need to use
"org.springframework.jms.connection.CachingConnectionFactory". As of spring
2.5.6, this supports caching of connection/sessions/consumers/producers and
is strongly recommended to use with JmsTransactionManager!
--
View this message in context: http://www.nabble.com/JmsComponent-issue-with-spring%27s-JmsTransactionManager-is-used-tp21697364s22882p21741460.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: JmsComponent issue with spring's JmsTransactionManager is used
Posted by chrajanirao <ra...@gmail.com>.
May be we shoud use CACHE_NONE when using JmsTransactionManager so that it
creates a new connection/session/consumer for every message? That's bad!
--
View this message in context: http://www.nabble.com/JmsComponent-issue-with-spring%27s-JmsTransactionManager-is-used-tp21697364s22882p21698182.html
Sent from the Camel - Users mailing list archive at Nabble.com.
Re: JmsComponent issue with spring's JmsTransactionManager is used
Posted by James Strachan <ja...@gmail.com>.
2009/1/28 chrajanirao <ra...@gmail.com>:
> Hi,
>
> It seems to me that Spring's DMLC implementation has a flaw/bug when
> JmsTransactionManager and CACHE_SESSION is used. It seems, spring is
> creating a session upfront once as we have cache session and a new session
> for every message in JmsTransactionManager. The cached session is being used
> for receiving. Hence if you don't specify sessionTransacted=true but supply
> the TX manager, the non-transacted cached session is used for consuming
> messages. This is a serious problem.
Let me just check I follow you. You're saying there is a problem if
you don't want to use transacted sessions but do want to use
CACHE_SESSION, then DMLC creates a new session each time due to the
presence of teh JmsTransactionManager right?
If thats the case, its easy to work around in Camel; we can just not
configure the transaction manager if transacted = false right?
> Although this is a spring issue, I wanted to bring it up here as Camel is
> enforcing that you supply a Tx manager when sessionTransacted=true and it
> degrades performance by creating a new session evetytime and not even use it
> consume messages.
Oh hang on are you saying Spring creates a new session every time when
using transacted=true?
--
James
-------
http://macstrac.blogspot.com/
Open Source Integration
http://fusesource.com/