<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">This will be tackled in 4.2: <a href="https://jira.jboss.org/browse/ISPN-615">https://jira.jboss.org/browse/ISPN-615</a><div><a href="https://jira.jboss.org/browse/ISPN-615"></a><br><div><div>On 20 Aug 2010, at 12:46, Mircea Markus wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Let me detail on this a little more: the optimisation refers to cache.lock() not to perform remote locks on ALL data owners, but only on the main data owner.<div>This way , if session affinity is used for enforcing key locality then cache.lock() would only acquire lock within the same JVM - i.e. very good performance without loosing eager's locking semantics. If the cluster changes, and the key is rehashed on a different node, than eager locking would do an RPC - but for many clusters the topology changes are infrequent. </div><div>Another problem that raises is that of consistency during node failures: if K is on node A and it was locked by a tx originated on node B. If A fails then we can invalidate the transaction on B, so that it would rollback.</div><div>Another interesting race condition Sanne raised is with re-hashing: "i<span class="Apple-style-span" style="font-family: 'Lucida Grande'; ">t needs to be atomic to know who is the owner and aquire the lock, or the owner might be moved and you're locking on the wrong node (only)"</span></div><div><div>I think this is not related to this optimisation in particular, but stands for eager locking in general - any idea how this is handled btw? </div><div>Cheers,</div><div>Mircea</div><div><br><div><div><div>On 20 Aug 2010, at 11:04, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Not sure I understand - are you proposing that the RPC for LockControlCommands are always async if the keys are generated using the key affinity service?<br><br>On 19 Aug 2010, at 16:29, Mircea Markus wrote:<br><br><blockquote type="cite">Hi,<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Here is the scenario, N=numOwners<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">TM.start()<br></blockquote><blockquote type="cite">c.lock(a); //this makes N (might me less) RPCs to acquire locks <br></blockquote><blockquote type="cite">c.get(a)<br></blockquote><blockquote type="cite">...<br></blockquote><blockquote type="cite">TM.commit(); // this would do an N calls for prepare/commit. Might happen async.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">By using the key affinity service, one might enforce a tx to operate on "local" keys (i.e. keys that are hashed on the same node where the tx was started). <br></blockquote><blockquote type="cite">Now, if we would be able to *only* eager lock the main data owner (v.s. N RPCs for lock acquisition locks) than eager locking would be as fast as the non-eager locking for this scenario. <br></blockquote><blockquote type="cite">What happens with the TX if the data owner crashes and only one copy is locked? We would need to invalidate the transaction at originator's side, which I think is possible.<br></blockquote><blockquote type="cite">For async repl with N >= 2 and key affinity the performance benefit for eager locking would be close to local puts: which is huge. <br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">This use case was brought by Erik ( cc)- please add you comments if something is missing. What do you think about this optimisation?<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite">Mircea <br></blockquote><blockquote type="cite">_______________________________________________<br></blockquote><blockquote type="cite">infinispan-dev mailing list<br></blockquote><blockquote type="cite"><a href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br></blockquote><blockquote type="cite"><a href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br></blockquote><br>--<br>Manik Surtani<br><a href="mailto:manik@jboss.org">manik@jboss.org</a><br>Lead, Infinispan<br>Lead, JBoss Cache<br><a href="http://www.infinispan.org">http://www.infinispan.org</a><br>http://www.jbosscache.org<br><br><br><br><br><br>_______________________________________________<br>infinispan-dev mailing list<br>infinispan-dev@lists.jboss.org<br>https://lists.jboss.org/mailman/listinfo/infinispan-dev<br></div></blockquote></div><br></div></div></div></div></blockquote></div><br></div></body></html>