cxf-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Kulp <>
Subject Re: Question about JMS Session Pool
Date Wed, 03 Sep 2008 14:53:26 GMT

Actually, one more note: 

He STRONGLY suggests not writing any JMS code in the JMS transport at all:

<jstrachan> dkulp: don't even think of writing any JMS code within cxf, just 
use spring message listener container
<jstrachan> you can configure the spring JMS stuff however you want
<jstrachan> we use URIs in camel for example
<jstrachan> seriously, delete your jms code, just use spring however you wanna 
use it

I don't know all the details about it, but apparently if you use the Spring 
jms/messaging stuff, it will work with the Spring transactions and security 
and such which doesn't work with "pure jms" stuff.   One reason we've seen 
for not using our JMS and instead using Camel or Mule or similar is due to 
the lack of spring transaction support.  It might be a good idea to grab the 
Camel and/or ServiceMix JMS code (probably Camel) and use that as more of a 
starting point.

Also, the latest public draft of the SOAP/JMS stuff is at:


On Wednesday 03 September 2008 10:23:42 am Daniel Kulp wrote:
> I just asked James Strachan and he said:
> <jstrachan> dkulp: but yes, you've gotta cache sessions
> <jstrachan> and consumers
> I don't know the details, but since he knows the insides of ActiveMQ pretty
> well, I'd take his advise.   :-)
> Dan
> On Tuesday 02 September 2008 5:00:38 pm Christian Schneider wrote:
> > Hi,
> >
> > I am just working an a refactoring of the JMS Transport. In the module
> > there is an implementation of a session cache.
> >
> > As we later want to switch to SpringTemplate and Spring
> > ListenerContainer I want to get rid of as much pooling implementation as
> > possible.
> > So my question is: Do we really need a session cache. As far as I
> > understood from JMS specs sessions are lightweight short lived objects.
> > So I think it would not harm to create a new session for each message
> > and destroy it later. The same is true for producers.
> >
> > The connection on the other hand has to be cached as it is costly to
> > create. I think the connection could be stored as a simple attribute of
> > JMSConduit or JMSDestination.
> > As far as I know it is thread safe too.
> >
> > What is your knowledge about this?
> >
> > Best regards
> >
> > Christian

Daniel Kulp

View raw message