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

Environment

WildFly 8.1.0.Final

Activity

Show:
Arcadiy Ivanov
December 19, 2014, 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.

Arcadiy Ivanov
December 22, 2014, 9:31 PM

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

Gail Badner
January 6, 2015, 8:34 AM

Fixed in master and 4.3.

Arcadiy Ivanov
January 6, 2015, 8:36 AM

Thanks!

Gail Badner
January 6, 2015, 8:00 PM

Closing in preparation for releasing 4.3.8.

Assignee

Gail Badner

Reporter

Arcadiy Ivanov

Fix versions

Labels

None

backPortable

None

Suitable for new contributors

None

Requires Release Note

None

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure