Use CONNECTIONNAMELIST or CCDT in a connection pool

Some Java EE environments, for example, WebSphere Application Server, provide a JMS connection pool. container that can be used to run Java SE applications.

Applications that create a connection using a connection factory that has been defined in the Java EE environment either obtain an existing free connection from the connection pool for this connection factory, or a new connection if there is not a suitable one in the connection pool.

This can have implications if the connection factory has been configured with either the CONNECTIONNAMELIST or CCDTURL property defined.

The first time the connection factory is used to create a connection, the Java EE environment uses either the CONNECTIONNAMELIST. or the CCDTURL to create a new connection to the IBM MQ system. When this connection is no longer required, it is returned to the connection pool where the connection becomes available for reuse.

If something else creates a connection from the connection factory, the Java EE environment returns the connection from the connection pool, rather than using the CONNECTIONNAMELIST or the CCDTURL properties to create a new connection.

If a connection is being used when a queue manager instance fails, the connection is discarded. However, the contents of the connection pool might not be, which means that the pool can potentially still contain connections to a queue manager that is no longer running.

In this situation, the next time a request is made to create a connection from the connection factory, a connection to the failed queue manager is returned. Any attempts to use this connection fail, as the queue manager is no longer running, causing the connection to be discarded.

Only when the connection pool is empty, will the Java EE environment use the CONNECTIONNAMELIST or CCDTURL properties to create a new connection to IBM MQ.

Due to the way the CONNECTIONNAMELIST and CCDTs are used to create JMS connections, it is also possible to have a connection pool that contains connections to different IBM MQ systems.

For example, assume that a connection factory has been configured with the CONNECTIONNAMELIST property set to the following value:
CONNECTIONNAMELIST = hostname1(port1), hostname2(port2)

Suppose that the first time an application tries to create a connection to a stand-alone queue manager from this connection factory, the queue manager running on the system hostname1(port1) is not accessible. This means that the application ends up with a connection to the queue manager running on hostname2(port2).

Another application now comes along and creates a JMS connection from the same connection factory. The queue manager on hostname1(port1) is now available, so a new JMS connection is created to this IBM MQ system and is returned to the application.

When both applications have finished, they close their JMS Connections, which causes the connections to be returned to the connection pool.

The result is that the connection pool for our connection factory now contains two JMS connections:

  • One connection to the queue manager running on hostname1(port1)
  • One connection to the queue manager running on hostname2(port2)

This can lead to issues relating to transaction recovery. If the Java EE system needs to roll back a transaction, it needs to be able to connect to a queue manager that has access to the transaction logs.

Parent topic: Use automatic client reconnection in Java EE environments