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
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.
Fixed in master and 4.3.
Closing in preparation for releasing 4.3.8.