[infinispan-dev] Ideas for locking improvements

[Sanne Grinovero]

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

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