[infinispan-dev] Ideas for locking improvements

[Sanne Grinovero]

2011/5/18 Manik Surtani <manik at jboss.org>:
> 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.

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).

>
> 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 ...

If a single key is involved, obviously not more than one node. When
multiple keys are involved, then each owner would want to ping the new
key owner; but if a single node crashed, isn't it the case that the
ownership of these locks is all moved to only two nodes, the next and
previous on the wheel ? So basically the nodes having a lock would
aggregate one RPC each to ~2 nodes.
Also the amount of network traffic is
 -  less than whatever traffic would be caused to re-acquire the same
locks & values to retry the transaction, which would likely happen in
case we did not apply these optimisations
 -  reduced anyway because of the algorithm

Sanne

>
> Overall, good stuff though, some very good ideas here.  :-)
>
> Cheers
> Manik
>
>
> On 13 May 2011, at 11:35, Sanne Grinovero wrote:
>
>> Hello all,
>> as some of us met recently at events, we've been discussing some
>> details about the current locking implementations and possible
>> improvements.
>>
>> Some interesting ideas came out and we've been writing them down on
>> the wiki so that everyone can be involved:
>> http://community.jboss.org/wiki/PossibleLockingImprovements
>>
>> as always, more feedback, comments and more suggestions are welcome.
>> Please bear with us if something is not very clear as they are drafts
>> of unimplemented ideas, so if you see something that you like to know
>> more about please start a discussion or comment about it and we'll try
>> to polish the explanation, refining the ideas.
>>
>> Cheers,
>> Sanne
>> _______________________________________________
>> infinispan-dev mailing list
>> infinispan-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>
> --
> Manik Surtani
> manik at jboss.org
> twitter.com/maniksurtani
>
> Lead, Infinispan
> http://www.infinispan.org
>
>
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev
>