[infinispan-dev] locking optimisations reloaded

[Mircea Markus]

On 25 May 2011, at 00:08, Paolo Romano wrote:

> I agree with you that lock contention has a dramatic effect on performance of transactional's workload and these ideas are interesting.
> 
> About solution 4, I may be missing something but, referring to the example mentioned here [1], I believe that you may incur in the following pattern of messages which would endanger consistency:
> 
> N3: receives T1, acquires lock on c, reply positively to the prepare to N1
> N3: receives T2, blocks on lock acquisition on c
> N1: receives positive reply on reply for T1, broadcasts commit message for T1 to N3, N4 .... but the message to N4 gets delayed ...
> N3: receives commit message for T1, writes back c<-T1, unblocks T2, replies positively for T2' s prepare to N2
> N2: receives positive reply on reply for T2, broadcasts commit msg for T2 to N3, N4
> N4: receives commit message for T2 (before that for T1), writes back c<-T2
> N4: receives commit message for T1, writes back c<-T1,
> N3: receives commit message for T2, writes back c<-T2
> 
> and in the end N3,N4 apply in different order the writes on c, ending up in inconsistent states (N3 has c=T2, N4 has c=T1).
> 
> In order to fix this, you could force causality order in the delivery of the commit messages (that trigger the writeback), which could be trackable using vector clocks (at least at a first thought!).
This is indeed a very valid scenario that would cause inconsistencies. I like the idea of using vector clocks for this, as it wouldn't require any additional RPC's, but some payload for serializing the vclocks.
> 
> Cheers,
>     
>     Paolo
> 
> PS: We've developed a TPC-C-like benchmark for Radargun (using a manual mapping of objects to keys), which happens to generate extremely high contention and might represent an additional testing tool (with a less synthetic workload) for this kind of optimizations... we're polishing the code and we would then be glad to contribute to the project if you find it interesting.
Nice! That would be very good for as as well, as we need to monitor the impact these changes have on the throughput. Please let me know if there's anything I can help you with.
> 
> PPS: I'm cc-ing cloudtm-discussion as I believe that this thread may be of interest also for this project.
> [1] http://community.jboss.org/wiki/PossibleLockingImprovements

Thanks for the very good point around consistency!


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/infinispan-dev/attachments/20110525/30dd8768/attachment-0001.html