Bugzilla – Full Text Bug Listing
| Summary: | MaxDB does not support FOR UPDATE locking with queries that involve multiple tables | ||
|---|---|---|---|
| Product: | z_Archived | Reporter: | Adrian Goerler <adrian.goerler> |
| Component: | Eclipselink | Assignee: | Nobody - feel free to take it <nobody> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | P3 | CC: | andreas.fischbach, eclipselink.incubator-inbox, krum.tsvetkov, sabine.heider |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | maxdb | ||
| Bug Depends on: | 326799, 327472 | ||
| Bug Blocks: | 284657 | ||
| Attachments: | |||
|
Description
Adrian Goerler
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 The Eclipselink project has moved to Github: https://github.com/eclipse-ee4j/eclipselink |