Remove after get with optimistic lock fails

Description

Whenever an entity is retrieved with an optimistic lock and then later is removed within the same transaction, an OptimisticLockException is thrown incorrectly.

This is caused by the lock being incorrectly tracked altogether in case of an explicit optimistic lock. The unlocked/default lock behavior tracks entity versions correctly deleting entity even with optimistic check.

EclipseLink, being a reference implementation, behaves correctly in this case.
=====

Running the attached test case the following behaviors can be observed:

Insert + Commit, Get unlocked + Delete + Commit = OK

Insert + Commit, Get + LockModeType.OPTIMISTIC + Delete + Commit = OptimisticLockException

Attachments

Linked issues

is duplicated by

HHH-8161

OptimistickLockException thrown in EntityManager commit() when locked entity was removed

HHH-9363

EntityManager.remove after EM.lock results in OptimisticLockException

Activity

Show:

Former user January 6, 2015 at 8:00 PM

Closing in preparation for releasing 4.3.8.

Arcadiy Ivanov January 6, 2015 at 8:36 AM

Thanks!

Former user January 6, 2015 at 8:34 AM

Fixed in master and 4.3.

Arcadiy Ivanov December 22, 2014 at 9:31 PM

PR reported for master to avoid conflicts: https://github.com/hibernate/hibernate-orm/pull/861

Arcadiy Ivanov December 19, 2014 at 5:06 PM

Is there going to be any review/response/reaction to this bug? The patches are submitted along with unit tests. This issue impacts EJB compositing with optimistic locking and we have to produce patched WildFly distros because this issue isn't merged and isn't even reviewed.