Workload from Web or EJB container
The number of threads in the Web and EJB containers controls the upper limit for the number of simultaneous accesses to JMS resources.
Queue Connection Factory (QCF) objects manage the pool of objects needed to access the underlying messaging system.
- Maximum sessions in session pool on QCF
- Maximum connections in connection pool on QCF
The number of QueueSessions and QueueConnections is dependent on the number of requests from Web and EJB containers and on how the application has been written to use these objects.
The figure below shows a typical way in which requests might flow in to an application. In this example all access to the QCF is through the EJB container and messages are only being placed on the queue. On each set of requests denoted by the arrows, is a tag that represents the controlling factor on how many simultaneous requests can reach that particular resource.
As requests arrive, a proportion of them require use of JMS resources. There has to be enough of these resources available to handle all the requests. If there are not enough JMS resources available then requests will have to wait for them to become free. This could lead to a time out and requests having to be re-submitted.
Ideally, each request should only ever require the use of one QueueConnection and one QueueSession at any time. Programming in this manner avoids a deadlock situation. However, it is possible to use more than one of each or cache the QueueConnection and use across many threads as it is thread safe (the QueueSession object is not thread safe - one is needed for each thread). So the number of QueueConnection objects and QueueSession objects can vary both on the number of requests requiring JMS and on how many objects that request will use.
Within the definition of a QCF it is possible to change the number of QueueSession objects and QueueConnection objects that are available to the application.
Request flow for Web and EJB containers accessing JMS resource
You can view the connection pool and session pool objects in the configuration information of the QCF definition at the correct level of scope for your application. See Choosing optimal configuration settings for more information on using scope when defining JMS objects.
The connection pool and session pool settings on a QCF settings page
Within these two options it is possible to set a minimum and maximum value for how many connections and sessions are available for the application to use.
Every QueueConnection has its own pool of QueueSession objects. This means that if the connection pool has a maximum of 5 and the session pool has a maximum of 10, providing the application is written to do this, there can be up to 50 QueueSessions open, 10 on each of the QueueConnections.
More information about setting these values and some other settings that can affect performance can be found in Choosing optimal configuration settings. For information on monitoring these values in real time see Monitoring JMS performance within Tivoli Performance Viewer.
WebSphere is a trademark of the IBM Corporation in the United States, other countries, or both.
IBM is a trademark of the IBM Corporation in the United States, other countries, or both.
Tivoli is a trademark of the IBM Corporation in the United States, other countries, or both.