Just want to chip in my two cents on this issue (being the reporter of the issue marked as duplicate of this one). For us this really is an issue. This behaviour also exists for LockModeType.READ. In this case, the same exception is being thrown, as the checking is also delayed. In this case, using pessimistic locking is not an option.

As indicated in my own issue, EclipseLink seems to expose the expected behaviour: if I remove the affected entity, no checking should be performed, i.e. the lock should be removed. I think the API is lacking here, but what I would expect is (given a entityManager.lock() has been done)

• Remove, clear, evict cancel the lock. Remove() performs a check anyway during execution, and afterwards there is no way to see any changes done to this entity. Clear/Evict() indicate to me that I'm not interested anymore in this entity, i.e. also not in the lock.
• Repeated calls to lock() should result in only one lock being active (it is debatable whether this should be the last one issued or the "highest/most strict" one).