<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 18 May 2011, at 12:44, Manik Surtani wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Some thoughts:<br><br>1. &nbsp;Suggesting deferring local locks till prepare-time: wouldn't this create a potentially large number of transaction failures? &nbsp;Since write skews and overwriting may become a problem if this is allowed.<br></div></blockquote>Not sure I get you, can you please detail.<br><blockquote type="cite"><div><br>2. &nbsp;Good point, except that how do you deal with failover, e.g., if the primary owner fails before broadcasting locks on other data owners (its peer group for a given key)? </div></blockquote>E.g. in the digram, if N3 fails before triggering 2 then N1 will be notified and can reissue the put to the new owner.&nbsp;</div><div>More interesting what happens if 2 is successful and N3 fails before ack to N1. This needs some more thought..<br><blockquote type="cite"><div>&nbsp;Further, doesn't this approach reduce parallelism in unicasts? &nbsp;E.g., currently, N1 sends requests to N3 and N4 in parallel. &nbsp;With the proposed scheme, N1 will send a request to N3, and then N3 sends one to N4, in sequence.<br></div></blockquote>this is documented: the optimisation only makes sense when there's high contingency on same key.<br><blockquote type="cite"><div><br>3. &nbsp;Need to think more about this, around implications of correctness of lock acquisition is reordered. &nbsp;But in terms of algorithm, sorting on identity hashcode won't work since this will be different on different requestor JVMs. &nbsp;<br></div></blockquote>The algorithm does NOT sort on identity hash code, but on CH. For conflict resolution (i.e. two keys that have same consistent hash) it can use object's hash code (default) or allow user to specify a hash code function if needed.&nbsp;<br><blockquote type="cite"><div><br>4. &nbsp;The "alternate solution" here does not cover the case of N3 failing before it propagates the lock to N4, thereby invalidating the prepared state of both tx1 and tx2. </div></blockquote>There's no lock propagation from N3 to N4..<br><blockquote type="cite"><div>&nbsp;Does this just mean that tx1 and tx2 fail/rollback?<br><br>5. &nbsp;This sounds good, except that doesn't a lock coordinator failing result in a network storm of each and every node in the cluster which had 1 or more locks on the lock coordinator now pinging the new lock coordinator with a message? &nbsp;I presume these can be compacted into a single RPC per node, but still ... <br><br>Overall, good stuff though, some very good ideas here. &nbsp;:-)<br></div></blockquote><blockquote type="cite"><div><font class="Apple-style-span" color="#000000"><br></font>Cheers<br>Manik<br><br><br>On 13 May 2011, at 11:35, Sanne Grinovero wrote:<br><br><blockquote type="cite">Hello all,<br></blockquote><blockquote type="cite">as some of us met recently at events, we've been discussing some<br></blockquote><blockquote type="cite">details about the current locking implementations and possible<br></blockquote><blockquote type="cite">improvements.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Some interesting ideas came out and we've been writing them down on<br></blockquote><blockquote type="cite">the wiki so that everyone can be involved:<br></blockquote><blockquote type="cite"><a href="http://community.jboss.org/wiki/PossibleLockingImprovements">http://community.jboss.org/wiki/PossibleLockingImprovements</a><br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">as always, more feedback, comments and more suggestions are welcome.<br></blockquote><blockquote type="cite">Please bear with us if something is not very clear as they are drafts<br></blockquote><blockquote type="cite">of unimplemented ideas, so if you see something that you like to know<br></blockquote><blockquote type="cite">more about please start a discussion or comment about it and we'll try<br></blockquote><blockquote type="cite">to polish the explanation, refining the ideas.<br></blockquote><blockquote type="cite"><br></blockquote><blockquote type="cite">Cheers,<br></blockquote><blockquote type="cite">Sanne<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>twitter.com/maniksurtani<br><br>Lead, Infinispan<br>http://www.infinispan.org<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></body></html>