Community
Participate
Working Groups
Several test fail on SAP MaxDB that atempt to lock multiple tables: eclipselink.core.test: - PessimisticLockTest(mode=1) - PessimisticLockEmptyTransactionTest eclipselink.jpa.test: - testPESSIMISTIC_READLockWithNoChanges - testPESSIMISTIC_WRITELockWithNoChanges - testPESSIMISTIC_ExtendedScope - testPessimisticLockHintStartsTransaction - testLockWithJoinedInheritanceStrategy - testPESSIMISTIC_FORCE_INCREMENTLock - testGetLockModeType
On MaxDB, the desired behaviour can be achieved by appending "WITH LOCK [(NOWAIT)] EXCLUSIVE" to the select statement.
Using "WITH LOCK [(NOWAIT)] EXCLUSIV", the test testLockWithJoinedInheritanceStrategy deadlocks on MaxDB: The test atemps to pessimistically lock a "LargeProject" entity, which has inheritance strategy JOINED. The entity is firstly locked. With a second entity manager, it is atempted to obtain a lock with NOWAIT, which should fail with a PessimisticLockException. However, as the entity has joined inheritances, firstly the query (in the following referred to as "Q1") SELECT DISTINCT t0.PROJ_TYPE FROM CMP3_PROJECT t0, CMP3_LPROJECT t1 WHERE (((t0.PROJ_ID = ?) AND (t1.PROJ_ID = t0.PROJ_ID)) AND (t0.PROJ_TYPE IN (L, H))) (assumingly to determine the concrete class in the hierarchy). This query does not use NOWAIT. As the test is executed with isolation level READ_COMMITED, this query will block causing a deadlock. On Oracle, we are having consistent read and hence Q1 won't block. On MySQL, the test succeeds accidently: FOR UPDATE NOWAIT causes a syntax error which is somehow wrapped into an (expected) PessimiticLockException. This remains to be analyzed.
Created attachment 179499 [details] use "WITH LOCK [(NOWAIT)] EXCLUSIVE" for pessimistic locking on maxdb Checked in at rev 8237.
Created attachment 179500 [details] patch to avoid deadlock in testLockWithJoinedInheritanceStrategy
The patch https://bugs.eclipse.org/bugs/attachment.cgi?id=179500 does not fix testLockWithJoinedInheritanceStrategy but just avoids the deadlock and causes a failure instead. The issue remains to be discussed. Tested on Oracle -> OK MaxDB -> Failure, but no deadlock MySQL -> false OK (hides syntax error (see above))
Created attachment 179612 [details] patch submnitted to avoid deadlock in testLockWithJoinedInheritanceStrategy Reviewed by Michael O' Brien Tested on MaxDB -> testLockWithJoinedInheritanceStrategy now fails but does not deadlock any longer
Comment on attachment 179612 [details] patch submnitted to avoid deadlock in testLockWithJoinedInheritanceStrategy Checked in at #8244.
Issue is now solved for eclipselink.core.test: - PessimisticLockTest(mode=1) - PessimisticLockEmptyTransactionTest eclipselink.jpa.test: - testPESSIMISTIC_READLockWithNoChanges - testPESSIMISTIC_WRITELockWithNoChanges - testPESSIMISTIC_ExtendedScope - testPessimisticLockHintStartsTransaction - testPESSIMISTIC_FORCE_INCREMENTLock - testGetLockModeType remains to be analyzed for eclipselink.jpa.test: - testLockWithJoinedInheritanceStrategy
This issue is marked to be blocked by bug 326779 - I think that was a mistake as that issue has to do with a proposal provider for the b3 DSL editor.
All pessimistic locking tests are now passing.
The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink
