I can confirm that this issue is still present in 5.2.10.Final. Note that the attached test does not really indicate the severity of the problem. In a situation where OPTIMISTIC_FORCE_INCREMENT locks are used, the issue will cause an OptimisticLockException during the transaction commit the second time the entity is read and locked. And even if the application uses retry logic (as is typical) to recover by trying to repeat the transaction, the application will never recover because it continues to read the stale cached entity with the incorrect version number, even after rolling back the transaction and creating a new EntityManager.