PI44458: Simultaneous writes for the same key can result in a LockTimeoutException when using write behind function.

APAR status

• Closed as program error.

Error description

• When using the write behind function, in addition to updating
  the user maps, WXS must also write updates to the write behind
  maps which are later used by the Loader to write to the backend.
  
  When simultaneous updates of the same key are performed a
  deadlock can occur on the write behind maps (IBM_WB_QUEUE).  The
  deadlock results in a LockTimeoutException:
  
  com.ibm.websphere.objectgrid.LockTimeoutException:
  Local-44C4714E-6567-FCCF-E003-3C970EC40214 timed out after
  waiting 15000
  ms for lock mode X to be granted for map name:
  IBM_WB_QUEUE_1_employees, key: key1
  granted = S
  lock request queue
  ->[Local-44C4714E-6567-FCCF-E001-3C970EC40214, state = Granted,
  requested 15007 milli-seconds ago, marked to keep current mode
  false,
  snapshot mode 0, mode = S, thread name = Thread-10]
  ->[Local-44C4714E-6567-FCCF-E000-3C970EC40214, state = Granted,
  requested 15008 milli-seconds ago, marked to keep current mode
  false,
  snapshot mode 0, mode = S, thread name = Thread-13]
  ->[Local-44C4714E-6567-FCCF-E002-3C970EC40214, state = Granted,
  requested 15008 milli-seconds ago, marked to keep current mode
  false,
  snapshot mode 0, mode = S, thread name = Thread-11]
  ->[Local-44C4714E-6567-FCCF-E003-3C970EC40214, state = Waiting
  for 15001
  milli-seconds for conversion, marked to keep current mode
  false,
  

Local fix

Problem summary

• ****************************************************************
  * USERS AFFECTED:  Users of eXtreme Scale who use the write    *
  *                  behind function.                            *
  ****************************************************************
  * PROBLEM DESCRIPTION: When updating the internal queue maps   *
  *                      used for write behind function, the     *
  *                      locking pattern causes a deadlock       *
  *                      situation.                              *
  ****************************************************************
  * RECOMMENDATION:                                              *
  ****************************************************************
  Instead of getting a sharable (S) lock during commit
  processing, the write behind function was updated to now get
  an upgradable (U) lock in order to prevent a deadlock in the
  write behind queue maps.
  

Problem conclusion

• An interim fix is available for this APAR upon request.
  

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

  WS EXTREME SCAL

• Fixed component ID

  5724X6702

Applicable component levels

• R860 PSY

     UP