[infinispan-dev] FineGrainedAtomicMap preview

[Vladimir Blagojevic]

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/a4d107c6783ee7db6bd1bec35b8bef3fc2f51de7#diff-22

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/a4d107c6783ee7db6bd1bec35b8bef3fc2f51de7

Regards,
Vladimir