Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
EclipseLink/Development/JPA 2.0/pessimistic locking
Contents
Lock Modes / Pessimistic Locking
JPA 2.0 Root | Enhancement Request
Issue Summary
In JPA 2.0 the specification extends Entity Manager lock mechanism to include explicit support for pessimistic locking. EntityManager and Query APIs have been updated with an additional query hint/persistence unit property. The specification has extensive detail on expected behaviour that must be implemented.
See JPA 2.0 ED section 3.4.3, 3.4.4, 3.6.3 and 3.6.4 for details.
General Solution
As EclipseLink includes Pessimistic Locking functionality this feature should be limited to comprehensive implementation of the JPA functionality and behaviour without many core changes. Pessimistic Locking and Optimistic Locking LockModesTypes must be covered. As well current query and Entity operations support must be updated to comply with new Pessimistic locking constraints.
Open Issues
Will Target table mappings (uni-directional OneToMany, ElementCollections) require that target rows also be locked?
Important Notes
- Pessimistically locked object with version must still have version updated when entity is updated.
- A considerable amount of behaviour definition will be found in the java docs of the EntityManger and Query APIs
- for instance upon issuing a pessimistic lock call on find if the version from the database does not match that of the persistence context then an exception must be raised
Work Required
- Develop tests for testing access type settings
- approx 3 days
- Update Processing to process entire table
- approx 2 days - optimistic modes
- approx 4 days - pessimistic modes