IBM Support

PI30467: INCORRECT LOCKING BEHAVIOUR OF OPENJPA

Subscribe

You can track all active APARs for this component.

 

APAR status

  • Closed as program error.

Error description

  • incorrect locking behaviour of OpenJPA
    

Local fix

  • N/A
    

Problem summary

  • ****************************************************************
    * USERS AFFECTED:  All users of IBM WebSphere Application      *
    *                  Server V8.0.0, V8.5.0, and V8.5.5 who make  *
    *                  use of Pessimistic Locking.                 *
    ****************************************************************
    * PROBLEM DESCRIPTION: When two threads attempt to get a       *
    *                      Pessimistic Lock, one thread gets a     *
    *                      'false' lock.                           *
    ****************************************************************
    * RECOMMENDATION:                                              *
    ****************************************************************
    In this scenario two threads both attempt to get a pessimistic
    lock on an object, where one thread legitimately gets the
    lock, and the other gets a 'false' lock. To describe this
    issue, lets look at a test snippet of the test which is at the
    heart of the issue:
    PessimisticLockEntity entity =
    oem.find(PessimisticLockEntity.class, pKey);
    boolean locked = false;
    while (!locked) {
    try
    { oem.getFetchPlan().setLockTimeout(5000); oem.lock(entity,
    LockModeType.PESSIMISTIC_READ); locked = true; }
    catch (PessimisticLockException ple) {
    With this test, imagine the case where two threads call this
    code at roughly the same time. In this case, one thread should
    receive a lock, and the other thread should receive a
    PessimisticLockException (PLE). When running the above code,
    this is exactly what happens, as expected.  However, take the
    case where the thread with the lock (call it T1) then sleeps
    for a while, thus holding the lock, and the thread which got
    the PLE (call it T2) attempts to get the lock over and over
    again. When T2 tries to get a lock while T1 holds the lock, T2
    should continue to receive a PLE. However, in this scenario is
    was found that T2 "gets" a lock. That is, a PLE is never
    thrown because OpenJPA doesn't run SQL to obtain the lock.
    OpenJPA skips that step and thinks T2 has a lock. This gives
    T2 a false lock.
    

Problem conclusion

  • With this fix, code has been added to OpenJPA to properly
    handle the case where two threads attempt a Pessimistic Lock
    on a JPA entity.  This is done by ensuring proper SQL is
    run against the database to attempt to get a lock.
    
    The fix for this APAR is currently targeted for inclusion in
    Service Levels (Fix Packs) 8.0.0.11 and 8.5.5.6 of WebSphere
    Application Server versions 8.0.0, and 8.5.5.
    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 number

    PI30467

  • Reported component name

    WEBS APP SERV N

  • Reported component ID

    5724H8800

  • Reported release

    800

  • Status

    CLOSED PER

  • PE

    NoPE

  • HIPER

    NoHIPER

  • Special Attention

    NoSpecatt / Xsystem

  • Submitted date

    2014-11-26

  • Closed date

    2015-03-30

  • Last modified date

    2015-03-30

  • 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

  • R800 PSY

       UP

  • R850 PSY

       UP

[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSEQTP","label":"WebSphere Application Server"},"Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"8.0","Line of Business":{"code":"LOB45","label":"Automation"}}]

Document Information

Modified date:
28 April 2022