[infinispan-dev] conflicts resolution in DeltaAware

[Mircea Markus]

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

> 2011/4/21 Manik Surtani <manik at 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 at 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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110421/7e411dfd/attachment.html