Bugzilla – Full Text Bug Listing
| Summary: | MaxDB: test PessimisticLockingExtendedScopeTestSuite.testPESSMISTIC_ES5 fails with DEADLOCK | ||
|---|---|---|---|
| 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: | eclipselink.incubator-inbox, krum.tsvetkov, kwesi, sabine.heider |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | maxdb | ||
| Bug Depends on: | |||
| Bug Blocks: | 284657, 325839 | ||
| Attachments: | |||
|
Description
Adrian Goerler
This issue is likely a MaxDB bug. And needs to be investigated. It is followed up in SAP's bug tracking system as internal issue "3138792 2010". The outcome of the investigation is open. Created attachment 180666 [details]
Java file allowing to reproduce the issue without EclipseLink
Analysis of the repro (https://bugs.eclipse.org/bugs/attachment.cgi?id=180666) provided by Holger Becker, MaxDB: "Hi Adrian, In MaxDB the foreign key records are locked before the primary key record. This means in your case the delete on MY_BUG_A_D first tries to lock MY_BUG_D and MY_BUG_A. The first lock could be granted but the second one not because of the prior select with exclusive lock. So the delete have to wait but already hold one exclusive lock on MY_BUG_D. When the other task now tries to read this row the deadlock is detected and you got error 600. We could check if this behaviour could be changed so that the delete first locks the primary record (in your case MY_BUG_A_D) this might make the situation clearer and in your case it would avoid the deadlock But I think it won't avoid any deadlock if you work with foreign keys. Perhaps you could change the application logic with this knowledge because I could not tell you when we will change the MaxDB behaviour. Kind regards Holger" One option to get rid of the deadlock on MaxDB would be to lock EntyA up-front before removing EntyD from the collection. However, testPESSMISTIC_ES5 wants to test that the join table is locked as well by the EXTENDED LOCK scope. Hence, upfront-locking EntyA would change the test. Alternatively, a native query could be executed that queries the join table without accessing EntyD's table. Created attachment 181467 [details]
on MaxDB, use native query to assert repeatable read of join table without accessing EntyD's table
Created attachment 183552 [details]
on MaxDB, use native query to assert repeatable read of join table without accessing EntyD's table
Fixed test by using a native query on MaxDB Reviewed by Tom Tested on MaxDB Checked in at #8530 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 |