[z/OS]

Connection factory settings for ASF message-driven beans that use WebSphere MQ as the messaging provider on z/OS

You can tune a variety of connection factory settings to control the creation of connections and sessions for message-driven bean (MDB) work.

Connection factory settings

To attach an application and a server to a particular queue manager with authentication parameters, both applications and message listener ports are 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).

For each connection factory, you must specify messaging provider settings (for example, queue manager settings), connection pool properties, and session pool properties. The settings for a connection factory's connection pool maximum connections property and session pool maximum connections property depend on whether you are using the connection factory for a listener port, for an application, or for both.

Connection pool maximum connections settings

To avoid waiting for a JMS connection because a WebSphere® Application Server-defined limit has been reached, set the connection pool maximum connections to at least the sum of the following values:
The number of message-driven beans that are mapped to any listener port mapped on this connection factory
A message-driven bean might get a JMS connection in performing its application logic in onMessage(), for example:
  • Forwarding the message to another destination or sending a reply
  • Updating a log but performing no JMS-related calls of its own

In either case, count 'one' for this message-driven bean because this is the connection used by the listener port.

If the message-driven bean onMessage() logic gets one JMS connection, add the number of servant worker threads to the maximum connection count. If not, do not add the maximum connection count for this (MDB) application component.

The maximum connection count
First find the maximum number of connections obtained in a single application dispatch (typically ‘1'), by checking all applications that use this connection factory. Then multiply this number by the number of worker threads in a servant to calculate the maximum connection count.
Note:
  • Only count worker threads for one servant because each servant has its own connection factory with connection and session pools.
  • Also include other non-MDB application components that use this connection factory to perform JMS calls. But, regardless of how many MDB or non-MDB application components use this connection factory, if they each use only one JMS connection for each dispatch, the maximum connection count is the number of servant worker threads (not the number of applications multiplied by the number of servant worker threads).

Session pool maximum connections settings

For MDB listener port processing in all typical cases, 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 might 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 can 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, they 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 scenario:
  • Each servant has 12 worker threads. (The number of servants in the server is not important because 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 that 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.
Example 1 solution:
  • For connection factory CF1, count one for MDB1. The MDB1 application (which also uses connection factory CF1 to send its forwarding message) uses one JMS connection, for which you 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, count one for each of MDB2A and MDB2B. There are no applications that use CF2, (only the listener port infrastructure), so set the connection pool Maximum connections for connection factory CF2 equal to 2.
  • For each of the two connection factories, set the session pool Maximum connections value to 12.
Example 2 scenario:
  • Again, each servant has 12 worker threads. In this example you 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.
Example 2 solution:
  • Up to this point you counted that three connections are needed for connection factory CF1. However, there is also a servlet component that 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.

指出主題類型的圖示 概念主題



時間戳記圖示 前次更新: July 9, 2016 11:11
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=cprf_tunezmdb_cf
檔名:cprf_tunezmdb_cf.html