<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 21 Apr 2011, at 12:38, Sanne Grinovero wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>2011/4/21 Manik Surtani <<a href="mailto:manik@jboss.org">manik@jboss.org</a>>:<br><blockquote type="cite"><br></blockquote><blockquote type="cite">On 21 Apr 2011, at 11:10, Sanne Grinovero wrote:<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite"><blockquote type="cite">thanks for resuming this topic;<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">some more thoughts:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">2011/4/20 Manik Surtani <<a href="mailto:manik@jboss.org">manik@jboss.org</a>>:<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><blockquote type="cite">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.<br></blockquote></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I didn't delve yet into how Infinispan is managing locking, but it<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">seems every time we talk about it I get confused; sorry it seems my<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">assumptions don't match the implementation.<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">I have read<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite"><a href="http://community.jboss.org/wiki/LockingandConcurrency">http://community.jboss.org/wiki/LockingandConcurrency</a><br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">which states that Infinispan by default acquires locks lazily, i.e. at<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">transaction(batch) boundaries, possibly failing at this point if<br></blockquote></blockquote><blockquote type="cite"><blockquote type="cite">that's not possible.<br></blockquote></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">These are remote locks. Local locks are eager.<br></blockquote><br>So behaviour is different depending on who happens to be the owner of<br>the key I'm working on?<br>In that case I'd propose that the local operations should behave as<br>the remote, that would provide some consistency in behaviour - it's<br>totally nice the implementation optimizes where it can, but this<br>shouldn't leak out on different effects? Advertising Infinispan as<br>MVCC I wouldn't expect it to acquire eager locks without explicitly<br>asking for it.<br></div></blockquote>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].</div><div>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. </div><div><br></div><div>[1]<a href="http://en.wikipedia.org/wiki/Multiversion_concurrency_control">http://en.wikipedia.org/wiki/Multiversion_concurrency_control</a></div><div><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Thank you for clarifying this though, this finally explains why I had<br>such high locking contention on Lucene which brought me to enable<br>SKIP_LOCK flags in all cases it was possible, I was still haunted by<br>the idea that something wasn't clear.<br><br>Cheers,<br>Sanne<font class="Apple-style-span" color="#540000"><br></font></div></blockquote></div><br></body></html>