Examples of using the connection pool
The message-driven bean listener port component, and applications that perform outbound messaging, use a JMS connection pool.
How MDB listener ports use the connection pool
Assume you have a MDB deployed on a WebSphere Application Server Network
Deployment system, that is using IBM® MQ as the JMS provider. The MDB is deployed against a listener port
which is using a connection factory called, for example, jms/CF1, that has the
maximum connections property set to 2, which means that only two connections can
be created from this factory at any one time.
When the listener port starts up, the port attempts to create a connection to IBM MQ, using thejms/CF1 connection factory.
To do so, the port requests a connection from the connection manager. Since this is the first
time the jms/CF1 connection factory has been used, there are no connections in the
jms/CF1 free connection pool, so the connection manager creates a new one called,
for example, c1. Note, that this connection exists for the entire life of the
listener port.
Now, consider the situation where you stop the listener port using the WebSphere Application Server administrative console. In this case, the connection manager takes the connection, and puts it back into the free pool. However, the connection to IBM MQ remains open.
If you restart the listener port, the port once again asks the connection manager for a
connection to the queue manager. As you now have a connection (c1) in the free
pool, the connection manager takes this connection out of the pool and makes it available to the
listener port.
Now, assume that you have a second MDB deployed into the application server, and it is using a different listener port.
Suppose you then try to start a third listener port, that is also configured to use the
jms/CF1 connection factory. The third listener port requests a connection from the
connection manager, which looks in the free pool for jms/CF1 and finds that it is
empty. It then checks how many connections have already been created from the
jms/CF1 factory.
Since the maximum connections property for jms/CF1 is set to 2, and you have
already created two connections from this factory, the connection manager waits for 180 seconds (the
default value of the connection timeout property) for a connection to become available.
However, if you stop the first listener port, its connection c1 is put into the
free pool for jms/CF1. The connection manager retrieves this connection and gives
it to the third listener.
If you now try to restart the first listener, this listener has to wait for one of the other
listener ports to stop before the first listener can restart. If none of the running listener ports
is stopped within 180 seconds, the first listener receives a
ConnectionWaitTimeoutException error and stops.
How applications that perform outbound messaging use the connection pool
EJB1,
installed in the application server. The bean implements a method called
sendMessage() by:- Creating a JMS connection to IBM MQ from a factory
jms/CF1, usingconnectionFactory.createConnection(). - Creating a JMS session from the connection.
- Creating a message producer from the session.
- Sending a message.
- Closing the producer.
- Closing the session.
- Closing the connection, by calling
connection.close().
Assume that the free pool for the factory jms/CF1 is empty. When the EJB is
invoked for the first time, the bean attempts to create a connection to IBM MQ from the factory jms/CF1. As the free
pool for the factory is empty, the connection manager creates a new connection and gives it to
EJB1.
Just before the method exits, the method calls connection.close(). Rather than
closing c1, the connection manager takes the connection and puts it into the free
pool for jms/CF1.
The next time sendMessage() is called, the
connectionFactory.createConnection() method returns c1 to the application.
Assume that you have a second instance of the EJB running at the same time as the first instance.
When both instances are calling sendMessage(), two connections are created from the
jms/CF1 connection factory.
Now assume that a third instance of the bean is created. When the third bean invokes
sendMessage(), the method calls
connectionFactory.createConnection() to create a connection from
jms/CF1.
However, there are currently two connections created from jms/CF1, which equals
the value of maximum connections for this factory. Therefore, the
createConnection() method waits for 180 seconds (the default value of the
connection timeout property) for a connection to become available.
However, if the sendMessage() method for the first EJB calls
connection.close() and exits, the connection it was using, c1, is
put back into the free connection pool. The connection manager takes the connection back out of the
free pool and gives it to the third EJB. The call from that bean to
connectionFactory.createConnection() then returns, allowing the
sendMessage() method to complete.
MDB listener ports and EJBs using the same connection pool
The two previous examples show how listener ports and EJBs can use the connection pool in isolation. However, you can have both a listener port and an EJB running inside the same application server and creating JMS connections using the same connection factory.
You need to consider the implications of this situation
The key thing to remember is that the connection factory is shared between the listener port and the EJB.
For example, assume that you have a listener and EJB running at the same time. Both are using the
jms/CF1 connection factory, which means that the connection limit specified by the
maximum connections property for that factory has been reached.
If you try to start either another listener port, or another instance of an EJB, either has to
wait for a connection to be returned to the free connection pool for jms/CF1.