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!
_______________________________________________ infinispan-dev mailing list infinispan-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/infinispan-dev
