PK24773: HASHCODE USED FOR MANAGEDCONNECTION IS INCORRECT

6.1.0.2: WebSphere Application Server V6.1.0 Fix Pack 2 for Solaris
6.1.0.2: WebSphere Application Server V6.1.0 Fix Pack 2 for Linux
6.1.0.2: WebSphere Application Server V6.1.0 Fix Pack 2 for Windows
6.1.0.2: WebSphere Application Server V6.1.0 Fix Pack 2 for AIX
6.1.0.2: WebSphere Application Server V6.1.0 Fix Pack 2 for HP-UX
6.1.0.2: WebSphere Application Server V6.1.0 Fix Pack 2 for i5/OS

APAR status

• Closed as program error.

Error description

• Client creates a resource adapter that has individual
  characteristics, which means whenever they call getConnection
  on their ConnectionFactory implementation, i.e.
  ConnectionFactoryImpl, they have to provide a ConnectionSpec
  derivate class instance parameter. They use WebSphere
  ConnectionManager instance to manage the pool of connections.
  .
  When they request a connection with particular characteristics
  for the first time, everything works as expected. When the
  connection is of no more use for the application, it is
  returned to WebSphere Connection Pool. When the same connection
  is requested again, no new connection is created because one
  already exists within the pool.
  .
  Customer performs an experience which opened 10 connections
  with different credentials, i.e. with different arguments to
  the getConnection method of the ConnectionFactoryImpl, their
  ConnectionFactory implementation. The 10 connections are
  reflected in 10 different instances of ConnectionImpl class,
  their Connection implementation. Next the close method on these
  10 connections was invoked. The consequence was that the 10
  connection were returned to WebSphere ConnectionManager.
  Next, the same 10 initial getConnection method invocations on
  ConnectionFactoryImpl were repeated.
  .
  matchManagedConnection method in ManagedConnectionFactoryImpl
  (their ManagedConnectionFactory implementation) should always
  be invoked by ConnectionManager with first set of parameter
  including the connection that is to be reused.
  Sometimes it doesn't and this is the malfunctioning.
  .
  If you enabled the WAS.j2c trace, you will find the following
  entry in the trace:
    [5/10/06 14:35:25:592 EDT] 0000003a PoolManager   >
    ClaimVictim Entry
    [5/10/06 14:35:25:592 EDT] 0000003a PoolManager   >
    getMCWrapperFromMatch Entry
    [5/10/06 14:35:25:592 EDT] 0000003a ConnectionReq 2
    hashCode: 5@intranet, -956339670
    ..
    [5/10/06 14:35:25:592 EDT] 0000003a PoolManager   3   Claiming
    victim MCWrapper id 25d14874  Managed connection
    pt.moredata.connector.jca.impl.ManagedConnectionImpl@263d0874
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED: WebSphere Application Server version 6       *
  *                 users of JCA.                                *
  ****************************************************************
  * PROBLEM DESCRIPTION: In a mixed connection request           *
  *                      information object environment, a       *
  *                      matching connection may exist in the    *
  *                      connection pool, but it may not be      *
  *                      used.                                   *
  *                                                              *
  *                      This can result in extra connection     *
  *                      objects being destroyed and created.    *
  *                                                              *
  *                      If the system is under load,            *
  *                      this problem does not occur.            *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Example of problem:
  Customer performs an experience which opened 10 connections
  with different credentials, i.e. with different arguments to
  the getConnection method of the ConnectionFactory, their
  ConnectionFactory implementation. The 10 connections are
  reflected in 10 different instances of Connection class,
  their Connection implementation. Next the close method on these
  10 connections was invoked. The consequence was that the 10
  connection were returned to WebSphere ConnectionManager.
  Next, the same 10 initial getConnection method invocations on
  ConnectionFactoryImpl were repeated.
  
  All 10 connection should be found and reused.
  
  But the result was mixed with some of the connection reused,
  but others destroyed and with new connections created.
  

Problem conclusion

• Code was fixed to locate all available matching connections.
  
  Results are predictable.
  
  The fix for this APAR is currently targeted for inclusion
  in cumulative fixpack 6.0.2.13.
  Please refer to the recommended updates page for delivery
  information:
  http://www.ibm.com/support/docview.wss?rs=180&uid=swg27004980
  

Temporary fix

Comments

APAR Information

• APAR is sysrouted FROM one or more of the following:

• APAR is sysrouted TO one or more of the following:

Modules/Macros

• J2C
  

Fix information

• Fixed component name

  WEBSPH APP SERV

• Fixed component ID

  5724J0800

Applicable component levels

• R60A PSY

     UP

• R60H PSY

     UP

• R60I PSY

     UP

• R60P PSY

     UP

• R60S PSY

     UP

• R60W PSY

     UP

• R60Z PSY

     UP

• R61A PSY

     UP

• R61H PSY

     UP

• R61I PSY

     UP

• R61P PSY

     UP

• R61S PSY

     UP

• R61W PSY

     UP

• R61Z PSY

     UP