Fixes are available
8.5.5.6: WebSphere Application Server V8.5.5 Fix Pack 6
8.0.0.11: WebSphere Application Server V8.0 Fix Pack 11
8.5.5.7: WebSphere Application Server V8.5.5 Fix Pack 7
8.5.5.8: WebSphere Application Server V8.5.5 Fix Pack 8
8.0.0.12: WebSphere Application Server V8.0 Fix Pack 12
8.5.5.9: WebSphere Application Server V8.5.5 Fix Pack 9
8.5.5.10: WebSphere Application Server V8.5.5 Fix Pack 10
8.5.5.11: WebSphere Application Server V8.5.5 Fix Pack 11
8.0.0.13: WebSphere Application Server V8.0 Fix Pack 13
8.5.5.12: WebSphere Application Server V8.5.5 Fix Pack 12
8.0.0.14: WebSphere Application Server V8.0 Fix Pack 14
8.5.5.13: WebSphere Application Server V8.5.5 Fix Pack 13
8.0.0.15: WebSphere Application Server V8.0 Fix Pack 15
8.5.5.14: WebSphere Application Server V8.5.5 Fix Pack 14
8.5.5.15: WebSphere Application Server V8.5.5 Fix Pack 15
8.5.5.17: WebSphere Application Server V8.5.5 Fix Pack 17
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
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
Document Information
Modified date:
28 April 2022