Re: [infinispan-dev] Ideas for locking improvements

Some thoughts: 1. Suggesting deferring local locks till prepare-time: wouldn't this create a potentially large number of transaction failures? Since write skews and overwriting may become a problem if this is allowed. 2. 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)? Further, doesn't this approach reduce parallelism in unicasts? E.g., currently, N1 sends requests to N3 and N4 in parallel. With the proposed scheme, N1 will send a request to N3, and then N3 sends one to N4, in sequence. 3. Need to think more about this, around implications of correctness of lock acquisition is reordered. But in terms of algorithm, sorting on identity hashcode won't work since this will be different on different requestor JVMs. 4. 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. Does this just mean that tx1 and tx2 fail/rollback? 5. 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? I presume these can be compacted into a single RPC per node, but still ... Overall, good stuff though, some very good ideas here. :-) Cheers Manik On 13 May 2011, at 11:35, Sanne Grinovero wrote: -- Manik Surtani manik(a)jboss.org twitter.com/maniksurtani Lead, Infinispan http://www.infinispan.org