Re: [infinispan-dev] FineGrainedAtomicMap preview
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.
Mircea and others,
To answer my own question. The non-visibility of transactional changes
was not related to Infinispan tx plumbing but a simple fact that
AtomicHashMap class uses non-thread safe FastCopyHashMap delegate to
store actual key/value pairs. When I changed FastCopyHashMap to
ConcurrentHashMap my concurrent tx test started to pass.
Cheers,
Vladimir