In "Spring's JmsTemplate gotchas and recommendations," James Strachan points out some potential problems with how people can use Spring's JmsTemplate - namely, by not understanding how it might create a connection, a session, and a producer or consumer on every call.

The thing to remember is JmsTemplate is designed for use in EJBs using the EJB containers JMS pooling abstraction. So every method will typically create a connection, session, producer or consumer, do something, then close them all down again. The idea being that this will use the J2EE containers pooling mechanism to pool the JMS resources under the covers. Without using a pooled JMS provider from the EJB container this is the worst possible way of working with JMS; since typically each create/close of a connection, producer/consumer results in a request-response with the JMS broker.

After detailing another such problem (based on a misunderstanding of JMS' best practices), James offers the following suggestions (with the understandable pointers to projects James is involved in):

• Never use a regular ConnectionFactory unless you are totally sure it does all the pooling you need
• If using in an EJB ensure you use the EJB containers ConnectionFactory; otherwise consider using Jencks to create it for you
• If not using in an EJB then use Jencks to create the ConnectionFactory
• If you are only publishing messages and you are not in an EJB and you are using ActiveMQ then you can use the PooledConnectionFactory
• If you are consuming messages its probably simpler & more efficient & less likely to loose messages to avoid using the receive() method and use Message Driven POJOs instead - unless you absolutely must pull messages on demand from inside an EJB.

One aspect of this entry that may not be obvious at first glance is that there are other Java APIs that have the same kinds of problems (JavaMail comes to mind).

Seems that Spring regards pooling in general as beyond the scope of the springframework. I would receommend the Spring boys work Strachan's blog into their documentation or FAQ. Documentation Injection!

Seems that Spring regards pooling in general as beyond the scope of the springframework.

Spring often recommends reusing the J2EE container's capabilities such as for pooling & XA support.
Also Spring has support for general pooling such as for POJOs or JDBC connections via commons-pool.

In Spring 1.3 I think Juergen's working on a JMS consumer pooling layer which is kinda a mini-JCA container but that doesn't do XA and only works with inbound JMS - which can do the consumer side of JMS pooling.

Though if you've got a J2EE container (or can use Jencks), I'd recommend using that for pooling of JMS and XA JDBC resources as thats what its designed for, can work with or without XA and works well with inbound and outbound JMS as well as other APIs like JDBC and reuses Resource Adapters for the underlying resources.

I would receommend the Spring boys work Strachan's blog into their documentation or FAQ. Documentation Injection!

LOL :). Since writing that blog entry I figured it was kinda handy stuff to know so have added it to the ActiveMQ wiki if folks wanna link to it...

http://activemq.org/JmsTemplate+Gotchas

James
LogicBlaze

I see this happening in one of my project now with spring 2.5.5. Looks like It still exists... Thanks, Senthil Balakrishnan