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 we 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

• Create a JMS connection to IBM MQ from a factory jms/CF1, using connectionFactory.createConnection().
• Create a JMS session from the connection.
• Create a message producer from the session.
• Send 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 we 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, we can have both a listener port and an EJB running inside the same application server and creating JMS connections using the same connection factory.

We 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 we 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.