You can tune a variety of connection factory settings to
control the creation of connections and sessions for message-driven
bean (MDB) work.
The following concepts 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, 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
Note: The 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.
The 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
Note: The 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.
The 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.