L2 cache stores stale data when an entity is locked with OPTIMISTIC_FORCE_INCREMENT lock type
Description
Attachments
Activity
Jon Kranes September 19, 2017 at 3:40 PM
In case anyone else runs into this issue, it appears (for my application at least) that a simple workaround for the issue is to explicitly evict the entity being locked before issuing the lock, using entityManagerFactory.getCache().evict(class, primaryKey).
Jon Kranes May 8, 2017 at 7:12 PM
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.
Alex Snaps November 5, 2015 at 4:08 PM
Thanks for the provided test case, this really helps. Now I think this will require a bit more time than expected to figure out how to best address this.
I'll be off at Devoxx the entirety of next week. I may be able to look into things there, but my schedule is pretty busy.
Anyways, just a heads up: am looking into this, but expect slow progress for the 10 days to come.
Alex Snaps November 3, 2015 at 9:17 PM
Looks like I better am "alexsnaps" (this goes to my gmail, as it looks like they deleted this alexsnaps@terracotta.org alias again), but yeah, let me have a look at this...
Steve Ebersole November 3, 2015 at 9:06 PM
(or ) - could you take a look at this one?
If cache usage is TRANSACTIONAL, the second find() will find the entity with version=0. If cache usage is any other (READ_WRITE for example), the second find() will return the entity with version=1 (which is correct).
The reason of this behaviour is in TransactionalEhcacheEntityRegionAccessStrategy.putFromLoad. It does not check that the entity is stale and must NOT be cached in the cache. The same behaviour applies to Infinispan cache implementation.