[infinispan-dev] Ideas for locking improvements
Manik Surtani
manik at jboss.org
Wed May 18 13:35:29 EDT 2011
On 18 May 2011, at 17:36, Sanne Grinovero wrote:
> 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?
Single-VM. Hibernate 2LC in a non-clustered environment.
> 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?
I agree that in the clustered case it makes sense to defer lock acquisition to the prepare phase. Not so sure about the local case.
--
Manik Surtani
manik at jboss.org
twitter.com/maniksurtani
Lead, Infinispan
http://www.infinispan.org
More information about the infinispan-dev
mailing list