You can tune a variety of connection factory settings to control the creation of connections and sessions for MDB work.
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.
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.
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).
Typically for MDB listener port processing you set the session pool Maximum connections property to the number of worker threads in a single servant.
This is because JMS sessions are not shared across application dispatches or by the listener port infrastructure, even for clients of the same connection factory, and also because 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).
You can 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.
You might 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). Or you might prefer to manage fewer connection factory administrative objects.
The connections and sessions used for MDB processing cannot be shared (that is, cannot be used by more than one flow at a time). Therefore you should not treat pooling as a way of 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.