On 21 Apr 2011, at 12:38, Sanne Grinovero wrote:

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.
I don't think MVCC has to to with *when* the lock is acquired, it's rather about not acquiring locks for reads but only for writes[1].
What you are suggesting (late lock acquisition for writes) is more towards optimistic concurrency control we had in JBossCache - and that one didn't prove to be quite efficient mainly because of high memory consumption. 

[1]http://en.wikipedia.org/wiki/Multiversion_concurrency_control

Thank you for clarifying this though, this finally explains why I had
such high locking contention on Lucene which brought me to enable
SKIP_LOCK flags in all cases it was possible, I was still haunted by
the idea that something wasn't clear.

Cheers,
Sanne