Re: [infinispan-dev] Ideas for locking improvements

2011/5/18 Manik Surtani <manik(a)jboss.org&gt;: > > On 18 May 2011, at 13:32, Sanne Grinovero wrote: > >>> 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. >> >> I agree, but as far as I understood by talking to Mircea this is what >> the current implementation does: it acquired the locks locally but the >> key owners don't know about it until commit time. >> So from that I inferred that - while it surprised me - that if you're >> able to handle that then you should be able to handle the local locks >> using the same logic (defferring consistently). > > > True, but the way it is right now, at least in the non-clustered case transactions have a much greater chance of completion. > > No harm in 2 separate locking schemes for clustered and non-clustered though. You lost me here. What is a non-clustered case, and why does Infinispan care about it?

How does it currently solve the case that two transactions both locking K1 are working on two non-owner(K1) nodes, what happens to the second committing? And why should this be different than when they happen to run on the same node?