[z/OS]

Connection factory settings for message-driven beans on z/OS

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:
  1. One for each message-driven bean that is mapped to any listener port mapped onto this connection factory.
  2. The maximum number of connections for one dispatch multiplied by the number of work threads in a servant.

    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
Note:

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

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.

Important: You should not restrict the concurrent MDB work in a server by setting this session pool Maximum connections to less than the number of servant worker threads, because 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 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?

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.

Connection factories – examples

Example 1
Note:
The scenario:
  • Each servant has 12 worker threads. (The number of servants in the server is not important since each servant gets its own pools).
  • Listener port LP1 is mapped to connection factory CF1. Message-driven bean MDB1 is mapped to LP1. The onMessage() application code of MDB1 puts a new message onto a forwarding queue, and so MDB1 has a resource reference which is also resolved to CF1.
  • Also, in the same server, listener port LP2 is defined and mapped to connection factory CF2. Message-driven beans MDB2A and MDB2B are defined in the same ejb-jar file and are both mapped to LP2 with complementary JMS selectors. The onMessage() application code of MDB2A and MDB2B each does some logging, but neither message-driven bean makes any JMS API calls of its own.
The solution:
  • For connection factory CF1, we count one for MDB1. The MDB1 application (which also uses connection factory CF1 to send its forwarding message) uses one JMS connection, for which we count the number of worker threads (12), multiplied by one. Our total connection pool Maximum connections for connection factory CF1, then, is 13 = 12 + 1.
  • For connection factory CF2, we count one for each of MDB2A and MDB2B. There are no applications using CF2, (only the listener port infrastructure), so we set the connection pool Maximum connections for connection factory CF2 equal to 2.
  • For each of the two connection factories, the session pool Maximum connections value is set to 12.
Example 2
Note:
The scenario:
  • Again, each servant has 12 worker threads. In this example we only want to use a single connection factory, CF1.
  • Each of two listener ports LP1 and LP2 is mapped to connection factory CF1. The message-driven beans MDB1, MDB2, and MDB3 are part of three unique application EAR files. MDB1 is mapped to LP1, but MDB2 and MDB3 are each mapped to LP2.
The solution:
  • Up to this point we count that we need three connections for connection factory CF1. However, there is also a servlet component which puts messages on a queue and it uses the same connection factory CF1. So for connection factory CF1, the connection pool Maximum connections setting is 15 = 3 + 12.



Related information
Concepts and considerations for MDB settings on z/OS
Basic “listening in the controller” messaging flow
MDB throttle settings for message-driven beans on z/OS
Message-driven beans, heterogeneous workloads, and workload management on z/OS
Concept topic Concept topic    

Terms and conditions for information centers | Feedback

Last updatedLast updated: Aug 31, 2013 4:28:44 AM CDT
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=pix&product=was-nd-mp&topic=cprf_tunezmdb_cf
File name: cprf_tunezmdb_cf.html