IBM Support

Removal of internal Connection Pooling for WebSphere MQ Classes for JMS

Troubleshooting


Problem

A JMS application works as expected when using the WebSphere MQ V6 Classes for JMS. When the application is migrated to the WebSphere MQ V7 Classes for JMS, the application appears to suffer performance degradation.

Symptom

Analysis from the Queue Manager perspective when the application is running shows a large number of connections being created and closed.

Cause

The internal JMS connection pooling functionality has been removed from the WebSphere MQ V7 classes for JMS.

The connection pooling functionality provided by the WebSphere MQ V6 classes for JMS allowed connection handles (Hconns) to WebSphere MQ to be stored in a pool where they were available for reuse. This functionality was implemented using the WebSphere MQ classes for Java. This was possible because the WebSphere MQ V6 classes for JMS were implemented as a layer of code on top of the WebSphere MQ V6 classes for Java. In WebSphere MQ V7 the implementation of WebSphere MQ classes for JMS is no longer dependent on WebSphere MQ classes for Java. This means that the WebSphere MQ classes for JMS can no longer access features of the WebSphere MQ classes for Java.

When using the WebSphere MQ V6 classes for JMS inside of a Java EE application server, two levels of pooling were provided:
  • Java EE application servers provided JMS Connection Pools and JMS Session Pools for applications to use.
  • When the application server was configured to use the WebSphere MQ V6 classes for JMS, these JMS Connection and JMS Session Pools sat on top of the connection handle pooling provided by the WebSphere MQ classes for JMS.

This led to some confusion about how the JMS Connection and Session Pools provided by application servers worked. It might have looked like there were still open connections from the application servers to WebSphere MQ, even though the JMS Connection and JMS Session Pools were empty. This was because the connection handles associated with the JMS Connections and JMS Sessions that had been removed from the application server Connection and Session Pools were now in the underlying WebSphere MQ classes for JMS connection handle pool.

When the WebSphere MQ V7 classes for JMS are used in JEE Application Server environments, JMS Connection and JMS Session Pools are provided as follows:
  • For Inbound Communications, the JMS Connection Pools and JMS Session Pools are implemented by the WebSphere MQ JCA resource adapter.
  • For Outbound Communications, the JMS Connection Pools and JMS Session Pools are implemented by the JEE Application Server.

Resolving The Problem

Stand-alone applications, and applications running inside of non JEE application server environments such as Apache Tomcat, which use the WebSphere MQ V7 classes for JMS and require JMS Connection and JMS Session pooling need to be modified to implement their own pooling logic. 

[{"Type":"MASTER","Line of Business":{"code":"LOB45","label":"Automation"},"Business Unit":{"code":"BU053","label":"Cloud & Data Platform"},"Product":{"code":"SSYHRD","label":"IBM MQ"},"ARM Category":[{"code":"a8m0z00000008QSAAY","label":"Components and Features->Java \/ JMS"}],"ARM Case Number":"TS006311249","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"All Versions"}]

Document Information

Modified date:
24 August 2021

UID

swg21665128