PK02574: SCE NOT THROWN & CONNECTION POOL NOT CLEAR FOR SHAREABLE GLOBAL GETCONNECTION WHEN AN XAER_RMFAIL J2CA0030E TRANS ERROR OCCURS | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
![]() APAR status Closed as program error. Error description J2C Connection Pool NOT Purged properly for Shareable Global getConnection when an XAER_RMFAIL XA transaction error is received that doesn't generate a StaleConnectionException (SCE). All related instances of "Error during lazy enlistment." for XAER_RMFAIL scenarios need to be taken into account to be added to SCE to prevent connection pool leaks. Trace return codes identified DSRA0302E, J2CA0027E & J2CA0030E J2CA0027E, although J2CA0027E was already added for PQ84630 previously. Basic customer recreation scenario, results and a bit of developer correspondence all listed below to faciliate identification on and related pmr tracking. I created the test application and tried the following 4 operations after I generated 11 free connections and then run "force application all" on DB2. 1. access database using the Global Transaction and calling getConnection() 2. access database using the Global Transaction and calling getConnection(userid, password) 3. access database using the Local Transaction and calling getConnection() 4. access database using the Local Transaction and calling getConnection(userid, password) The results on each of the operations above are below: A. Set "Shareable" to res-sharing-scope of the datasource in web.xml 1. : ONLY 1 connection in the pool was cleared. 2. : ONLY 1 connection in the pool was cleared. 3. : ALL connections in the pool was cleared. 4. : ALL connections in the pool was cleared. B. Set "Unshareable" to res-sharing-scope of the datasource in web.xml 1. : ALL connections in the pool was cleared. 2. : ALL connections in the pool was cleared. 3. : ALL connections in the pool was cleared. 4. : ALL connections in the pool was cleared. For A. Set "Shareable" to res-sharing-scope of the datasource in web.xml 1. : ONLY 1 connection in the pool was cleared. 2. : ONLY 1 connection in the pool was cleared. I see the following in the trace. [2/21/05 20:54:12:971 JST] 56f20f0f WSJdbcConnect > fireConnectionErrorEvent [2/21/05 20:54:12:971 JST] 56f20f0f WSJdbcConnect e Handle is INACTIVE. Not sending CONNECTION_ERROR_OCCURRED. com.ibm.ws.rsadapter.jdbc.WSJccConnection@51a54f08 [2/21/05 20:54:12:972 JST] 56f20f0f WSJccConnecti > close com.ibm.ws.rsadapter.jdbc.WSJccConnection@51a54f08 [2/21/05 20:54:12:972 JST] 56f20f0f WSJccConnecti e state --> CLOSED [2/21/05 20:54:12:972 JST] 56f20f0f ConnectionMan > inactiveConnectionClosed [2/21/05 20:54:12:972 JST] 56f20f0f ConnectionMan < inactiveConnectionClosed [2/21/05 20:54:12:972 JST] 56f20f0f WSJccConnecti < close [2/21/05 20:54:12:972 JST] 56f20f0f WSJdbcConnect < fireConnectionErrorEvent The CONNECTION_ERROR_OCCURRED is not sent causing the connection pool not to be cleared. Normally when the handle is inactive, the connection has already been closed and the application is still trying to use it. This is not valid. Before running the test application, customer did the following step "I created the test application and tried the following 4 operations after I generated 11 free connections and then run "force application all" on DB2." Then he connected the DB again and ran the application. And the connections in free pool was expected to be invalid. Several attempts have already been made to force the connection pool to exercise the purge pool policy when an XAER_RMFAIL transaction error code occurs. The customer is running a test that was not considered in the last several fixes, so we are still seeing a problem with the XAER_RMFAIL processing. The test scenario is using a shared connection which is cleaned up and destroyed when the transaction is ending because of the transaction error code. This is the way shared connections work and we don't have a problem until we attempt to notify the connection pool with the already destroyed connection. Since the connection is destroyed, no notification is sent to the connection pool. The end result being that only ONE connecdtion is destroyed.Local fix Manually MAP or add any identified J2CA to SCE.Problem summary **************************************************************** * USERS AFFECTED: WebSphere Application Server users of JDBC * * and JCA. * **************************************************************** * PROBLEM DESCRIPTION: J2C Connection Pool is NOT Purged * * for shared connections in a global * * transaction when an XAER_RMFAIL XA * * transaction error is received that * * doesn't generate a * * StaleConnectionException (SCE). * **************************************************************** * RECOMMENDATION: * **************************************************************** J2C Connection Pool is not purged properly for Shareable Global getConnection when an XAER_RMFAIL XA transaction error occurs The customer test application used the following 4 operations after generating 11 free connections and then running "force application all" on DB2. 1. access database using the Global Transaction and calling getConnection() 2. access database using the Global Transaction and calling getConnection(userid, password) 3. access database using the Local Transaction and calling getConnection() 4. access database using the Local Transaction and calling getConnection(userid, password) The results on each of the operations above are below: A. Set "Shareable" to res-sharing-scope of the datasource in web.xml 1. : ONLY 1 connection in the pool was cleared. 2. : ONLY 1 connection in the pool was cleared. 3. : ALL connections in the pool was cleared. 4. : ALL connections in the pool was cleared. B. Set "Unshareable" to res-sharing-scope of the datasource in web.xml 1. : ALL connections in the pool was cleared. 2. : ALL connections in the pool was cleared. 3. : ALL connections in the pool was cleared. 4. : ALL connections in the pool was cleared. For A. Set "Shareable" to res-sharing-scope of the datasource in web.xml 1. : ONLY 1 connection in the pool was cleared. 2. : ONLY 1 connection in the pool was cleared. the following was found in the trace: [2/21/05 20:54:12:971 JST] 56f20f0f WSJdbcConnect > fireConnectionErrorEvent [2/21/05 20:54:12:971 JST] 56f20f0f WSJdbcConnect e Handle is INACTIVE. Not sending CONNECTION_ERROR_OCCURRED.Problem conclusion The connection pool is now being purged correctly for failing shareable connection tests 1 and 2. 1. access database using the Global Transaction and calling getConnection() 2. access database using the Global Transaction and calling getConnection(userid, password) With this fix, the results on each of the operations above are below: A. Set "Shareable" to res-sharing-scope of the datasource in web.xml 1. ALL connections in the pool was cleared. 2. ALL connections in the pool was cleared. The fix for this APAR is currently targeted for inclusion in 5.02.11 and 5.1.1.5. Please refer to the recommended updates page for delivery information: http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980Temporary fix Comments
APAR is sysrouted FROM one or more of the following: APAR is sysrouted TO one or more of the following: Modules/Macros
Publications Referenced
|
Product categories: Software > Application Servers >
Distributed Application & Web Servers > WebSphere Application
Server > General
Operating system(s):
Software version: 00A
Software edition:
Reference #: PK02574
IBM Group: Software Group
Modified date: Apr 21, 2005
(C) Copyright IBM Corporation 2000, 2008. All Rights Reserved.