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 <rajan...@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
