[infinispan-dev] Ideas for locking improvements
Mircea Markus
mircea.markus at jboss.com
Mon May 23 05:25:33 EDT 2011
On 18 May 2011, at 17:23, Manik Surtani wrote:
>
> 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.
I don't see how this would cause more failures even on the non-clustered mode: competing transactions fight for same locks in both approaches, just that "the battle" is delayed to prepare time. Especially if we add the lock-reordering optimisation that would result in no-deadlocks, I think the throughput should be better in both local and clustered scenarios.
More information about the infinispan-dev
mailing list