PH02713: CONTENTION FOR THE INTRINSIC LOCK IN THE JMSCONNECTIONHANDLE CREATESESSION METHOD.

8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
9.0.0.11: WebSphere Application Server traditional V9.0 Fix Pack 11
9.0.5.0: WebSphere Application Server traditional Version 9.0.5 Refresh Pack
9.0.5.1: WebSphere Application Server traditional Version 9.0.5 Fix Pack 1
9.0.5.2: WebSphere Application Server traditional Version 9.0.5 Fix Pack 2
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
9.0.5.3: WebSphere Application Server traditional Version 9.0.5 Fix Pack 3
8.5.5.20: WebSphere Application Server V8.5.5.20
8.5.5.18: WebSphere Application Server V8.5.5 Fix Pack 18
8.5.5.19: WebSphere Application Server V8.5.5 Fix Pack 19
8.5.5.16: WebSphere Application Server V8.5.5 Fix Pack 16
8.5.5.21: WebSphere Application Server V8.5.5.21

APAR status

• Closed as program error.

Error description

• Contention for the intrinsic lock in the
  JMSConnectionHandle.createSession method.
   The issue happens due to the performance delay in the backend
  (i.e, MQ/IIB/database).
  
  In JMS Connection pooling , when the call made to get a
  connection, the 1st createSession gets a free Session from the
  pool and does some work against it and the session is then
  closed so that goes back in the pool but if it is still
  associated with the unit-of-work then it wont be back to free
  pool.
  
  If another request happens on same thread (same LTC) , it makes
  call to createSession again,this will need to go through the
  synchronization in the JMSConnectionHandle before being given
  the original Session back. This could cause  contention on the
  locks (waiting for a first session to be realeased). The
  livelock may get resolved when the connection manager times out
  the request for a Session that holds the intrinsic lock .
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  WebSphere Application Server users of JMS   *
  *                                                              *
  ****************************************************************
  * PROBLEM DESCRIPTION: Unnecessary performance overhead,       *
  *                      including possible timeout waiting for  *
  *                      a Session indicated by J2CA0045E, may   *
  *                      occur.                                  *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  JMS Sessions are pooled by the application server and are also
  transactional.  When an application closes a Session it is
  returned to the pool but if the unit of work associated with
  the Session is still active the Session will only be available
  for re-use by the same transaction until the transaction is
  completed.
  It is therefore possible that the Session pool is full of
  Sessions that are already allocated to active transactions.
  If a new Session is required for a new unit of work and the
  pool is at its maximum size then the new request will block
  until a Session becomes free.  In the case where the
  transactions associated with the allocated Sessions in the
  pool attempt to reobtain their Session this results in a
  deadlock due to unnecessary Synchronization in the
  JMSConnectionHandle.createSession method.  This is because the
  intrinsic lock is held by the thread that is waiting for a
  Session to become free but the transactions that need to
  progress to completion are waiting for the intrinsic lock in
  order to reobtain their Sessions.
  The deadlock is resolved when the timeout mechanism for
  the thread waiting for a free Session occurs resulting in the
  application receiving a JMSException and message J2CA0045E is
  generated in the logs.
  More generally any request for a new Session that blocks
  waiting for a Session to become free in the pool will
  potentially block requests to reobtain Sessions unncessarily
  even if a Session does become free due to the completion of an
  associated transaction causing an unnecessary delay.
  

Problem conclusion

• The synchronization required in the
  JMSConnectionHandle.createSession was modified so that the
  request to allocate a Session from the pool is performed
  outside the synchronization block.
  
  The fix for this APAR is currently targeted for inclusion in
  fix packs 8.5.5.15 and 9.0.0.11.  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:

Fix information

• Fixed component name

  WEBS APP SERV N

• Fixed component ID

  5724H8800

Applicable component levels

• R700 PSY

     UP

• R800 PSY

     UP

• R850 PSY

     UP

• R900 PSY

     UP