Hey guys, I about to integrate FineGrainedAtomicMap into master but before I do I need your feedback. I particularly need feedback from users who where eagerly awaiting this feature (Sanne and others) and possibly their use/test cases of how they intended to use FineGrainedAtomicMap so we can integrate these use/test casesinto the test suite. I created a separate interface FineGrainedAtomicMap to distinguish it from AtomicMap. Yes, of course, if you declared a variable of type Map one could still assign both AtomicMap and FineGrainedAtomicMap to the same variable but this way we force users to distinguish them at least a bit. There is a separate factory method in AtomicLookup for FineGrainedAtomicMap. The best way to see how this works is to look at the test cases at https://github.com/vblagoje/infinispan/commit/a4d107c6783ee7db6bd1bec35b8... Mircea, I need your help regarding concurrent tx and FineGrainedAtomicMap. Have a look at FineGrainedAtomicMapAPITest#testConcurrentTx(the above link) as it is failing if I do *not* run two threads sequentially, i.e. there is a sleep of 2 sec to prevent concurrent tx running. Any ideas why is this happening? The test failed in the old locking architecture as well. In the old architecture, an entry was not wrapped with MVCCEntry because we do not look up (and lock) AtomicHashMap but we issues "synthetic/composite" lock requests for keys in that AtomicHashMap. If we look up and lock key for AtomicHashMap the the whole point of FineGrainedMap is lost as we would lock entire map. I noticed that AtomicHashMap was being wrapped with ImmortalEntry. Maybe this is why changes are not seen with concurrent tx, but how is it that the changes are seen if tx are not run concurrently? If you could demystify this for me I'd be grateful. The commit is here https://github.com/vblagoje/infinispan/commit/a4d107c6783ee7db6bd1bec35b8... Regards, Vladimir