You can tune a variety of connection factory settings to control the creation of connections and sessions for MDB work.
This topic describes the following concepts and considerations that affect your choice of connection factory settings:
Connection factory settings
To attach an application and a server to a particular queue manager with authentication parameters, applications and message listener ports are both bound to connection factories. The server uses the same administrative model to listen for messages arriving for delivery to message-driven beans as the application uses to exploit JMS, in that message listener ports are bound to a queue connection factory or topic connection factory and a corresponding queue or topic.
In addition to specifying the messaging provider settings (for example, queue manager settings) on connection factories, you also specify connection and session pool properties. In particular, for a connection factory, the values of the connection pool property Maximum connections and session pool property Maximum connections must be chosen with different considerations in mind, depending on whether you are using the connection factory for a listener port, for an application, or for both.
Connection pool maximum connections settings
First, in order to avoid waiting for a JMS connection, because of reaching a WebSphere Application Server-defined limit, the connection pool Maximum connections should be set to at least the sum of the following values:
To determine this maximum connection count, first find the maximum number of connections obtained in a single application dispatch (typically ‘1’), checking all applications that use this connection factory. Multiply this maximum number of connections by the number of worker threads in a servant. (See the following note for more information about this value.)
Note that only a single servant’s worker threads are counted here, because each servant gets its own connection factory with connection and session pools, although the Administrator defines only a single set of property values.
Clarification about part 2 of the preceding Maximum connection count:
A message-driven bean might or might not get a JMS connection in performing its application logic in onMessage(). For example, it might get a connection to forward the message to another destination or send a reply, or it might simply update some log and perform no JMS-related calls of its own.
In either case, we need to count ‘one’ for this message-driven bean in part 1 of the preceding Maximum connection count, as this is the connection used by the listener port. If the message-driven bean onMessage() logic gets one JMS connection, then we then add the number of servant worker threads to the Maximum connection count. If not, then we need not add to the Maximum connection count on behalf of this (MDB) application component.
Of course, other non-MDB application components which use this connection factory to perform JMS calls might cause the administrator to need to include part 2 of the overall Maximum connections count. But, regardless of how many MDB or non-MDB application components use this connection factory, if they each only use one JMS connection per dispatch, then the count in part 2 is only equal to the number of servant worker threads (not the number of applications multiplied by the number of servant worker threads).
Session pool maximum connections settings
This calculation is an easier one to make than it might first appear. For MDB listener port processing in all typical cases, the session pool Maximum connections property should be set to the number of worker threads in a single servant.
The reasons are the fact that JMS sessions are not shared across application dispatches or by the listener port infrastructure, even for clients of the same connection factory, along with the fact that there is a unique session pool for each JMS connection obtained from the connection factory (although the pool property settings are specified only once, at the connection factory level).
It is possible to imagine a case for which the same connection factory is used both by a listener port and an application, with the application having a higher Maximum connections requirement on the session pool setting, but this does not merit further discussion here.
Note: : It is possible to restrict the concurrent MDB work in a server by setting this session pool Maximum connections to less than the number of servant worker threads. This is not recommended. In such a case, an MDB work request could be dispatched over to a servant, without a session available to process the message. The worker thread at that point would then wait for a session to become available, tying up the valuable worker thread resource.
Should I use a few or many connection factories?
Some users may prefer to keep these calculations simple; for example, by creating a separate connection factory for each message-driven bean (in which case the connection pool Maximum connections property value could simply be set to 1). Others may prefer to manage fewer connection factory administrative objects.
The fact that the connections and sessions used for MDB processing cannot be shared (that is, cannot be used by more than one flow at a time) means that the desire to take advantage of pooling should not be considered a reason for using fewer connection factories. In other words, adding another connection factory does not prevent connection pooling that could otherwise be exploited by MDB listener port processing.
Connection factories – examples
Example 1:
The scenario:
The solution:
Example 2:
The scenario:
The solution: