-
Bug
-
Resolution: Done
-
Critical
-
7.0.2.Final
-
Workaround Exists
-
After a FineGrainedAtomicMap containing some data is deleted in a transaction, but then in the same transaction it's re-created, the next transaction will be able to read the original data which it contained.
Some pseudocode:
tx1.start(); am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true ); am.put(k1, v1); tx1.commit() tx2.start(); am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true ); am.put(k3, v3); AtomicMapLookup.removeAtomicMap( cache, cacheKey ); am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true ); am.put(k2,v2); tx2.commit() tx3.start(); am = AtomicMapLookup.getFineGrainedAtomicMap( cache, cacheKey, true ); am.contains(k1) == false; // FAILS! tx3.commit();
Also applies apparently to a normal AtomicMap if using DIST_SYNC.
I'm attaching a full test, which results in:
Failed tests: RepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null FineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null DistFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null DistRepeatableReadFineGrainedAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null DistRepeatableReadAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null DistAtomicMapAPITest>BaseAtomicHashMapAPITest.testInsertDeleteInsertCycle:596 null Tests run: 5636, Failures: 6, Errors: 0, Skipped: 0
- blocks
-
OGM-697 Loading...