2011/4/21 Manik Surtani <
manik@jboss.org>:
On 21 Apr 2011, at 11:10, Sanne Grinovero wrote:
thanks for resuming this topic;
some more thoughts:
2011/4/20 Manik Surtani <manik@jboss.org>:
I think changing the merging interface won't solve your problem since as others have pointed out, the AtomicMap is locked based on its key. So you won't be able to have concurrent updates to the AtomicMap anyway.
I didn't delve yet into how Infinispan is managing locking, but it
seems every time we talk about it I get confused; sorry it seems my
assumptions don't match the implementation.
I have read
http://community.jboss.org/wiki/LockingandConcurrency
which states that Infinispan by default acquires locks lazily, i.e. at
transaction(batch) boundaries, possibly failing at this point if
that's not possible.
These are remote locks. Local locks are eager.
So behaviour is different depending on who happens to be the owner of
the key I'm working on?
In that case I'd propose that the local operations should behave as
the remote, that would provide some consistency in behaviour - it's
totally nice the implementation optimizes where it can, but this
shouldn't leak out on different effects? Advertising Infinispan as
MVCC I wouldn't expect it to acquire eager locks without explicitly
asking for it.