Understanding JMS connection pools and session pools for better tuning

Body

This blog contains some common questions and answers that are related to the use of JMS connection pools and session pools. Hopefully this information will help you in your environment tuning efforts.

• Q: WebSphere MQ Queue Connection Factories in WebSphere Application Server releases contain both a connection pool and a session pool for configuration. When configuring the session pool, is this configuration for each connection? For example, if my connection pool has a maximum size of 10, and my session pool also has a maximum size of 10, does that mean that I have a total of 10 sessions available per connection, which would make it 100 sessions for 10 connections? Or, does this mean that there are only 10 sessions available to be used among 10 connections?
  
  A: The session pool setting applies to each JMS connection as this is the factory for sessions. Thus, you can have a maximum of 10 sessions for each connection and a maximum of 10 connections. So, in total, this means that you might have 100 channels (connections) open to the MQ Server.
   
• Q: What happens if my session pool has a maximum of 10 sessions and connections and I attempt to create a new session from a connection that exceeds this maximum session and connection? Does the pool grow? Is an exception thrown? If so, what kind of exception is seen?
  
  A: When the maximum number of connections and sessions is reached, and a request for a new connection or session is received, the pool manager waits for a period of time, which is defined in the Connection timeout property, for an available physical connection. If a connection is not available in the time period that is defined by the Connection timeout property, the Pool manager throws a ConnectionWaitTimeoutException. This information is documented in more detail in the Connection timeout section on the Session pool settings page of the WebSphere Application Server product documentation.
   
• Q: When closing a QueueConnection JMS in WebSphere Application Server with Connection Pooling configured, what exactly happens?
  
  A: When a connection is closed, it is returned to the connection pool, and the session to its session pool. Any QueueSender and QueueReceiver objects that are associated with the session are destroyed.
   
• Q: From a design perspective, is there a formula regarding the sizing of the WebSphere MQ JMS connection pool and JMS session pool with respect to the number of concurrent requests?
  
  A: A formula does not exist. However, we recommend that you set the Max Connections property for your connection pool to a value about 50% higher than your typical JMS connection concurrency. We also recommend that you set the Max Connections property for your session pool to approximately 50% more than the average number of concurrent sessions requested on a JMS Connection. The requirements really depend on the design of your application; in particular, how it uses JMS connections and sessions. You should also remember that the Max Connections property for your session pool is the maximum number of sessions that can be made from a single JMS Connection because a JMS connection is a factory for sessions.
   
• Q: How can I utilize a WebSphere MQ JMS session pool without having to manage the JMS connections in the application? It appears that if I have a JMS connection pool and a JMS session pool, I need to keep track of my connections in some collector object to use the number of sessions I have configured for use with each connection. How do I make use of those sessions in the session pool without having to maintain my own programmatic list of connections that are configured in the connection pool? For example, having retrieved a connection from the connection pool, what is the approach for creating sessions for multiple users without having to maintain that connection reference and a collector object in my application?
  
  A: JMS connections are non-shareable. Therefore, unless your application does something like caching a connection in a static class variable, which is definitely not recommended in practice, an Enterprise JavaBeans method has only a single JMS connection/JMS session pair per EJB method thread. Currently, the JCA Connection Manager does not support the sharing of non-transactional resources, such as a JMS connection. Thus, it must be handled in your application code. Note that, from a WebSphere MQ perspective, a JMS connection is very lightweight. It is the JMS session that is the heavyweight object. Also be aware that in the Oracle J2EE 1.4 specification, an application server must enforce an application so that it can only create a single JMS session from a JMS connection. A possible reason behind the Oracle decision is because of connection management considerations, and the fact that in J2EE 1.4, JMS providers are advised to be defined as JCA Resource Adapters.

water-swimming-pool-blue (modified) credit: (cc) Some rights reserved by Aquilatin