[infinispan-dev] locking optimisations reloaded

Paolo Romano romano at inesc-id.pt
Tue May 24 19:08:38 EDT 2011


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!).

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.

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

On 5/24/11 10:36 PM, Mircea Markus wrote:
> Hi,
>
> This is re: http://community.jboss.org/wiki/PossibleLockingImprovements
>
> I've created JIRAs for the locking optimisations as follows:
>
> #1: https://issues.jboss.org/browse/ISPN-1131
> #2: this seems to be just a particular case of #4
> #3: https://issues.jboss.org/browse/ISPN-1132
> #4: https://issues.jboss.org/browse/ISPN-1137
> #5: I think this is pretty much the same thing as #4, waiting for 
> Sanne to confirm that.
>
> Each JIRA also contains the design I have in mind for implementing them.
> I do think this will improve the transactional throughput 
> *significantly*, so any feedback much appreciated.
>
> Cheers,
> Mircea
>
>
> _______________________________________________
> infinispan-dev mailing list
> infinispan-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/infinispan-dev

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


More information about the infinispan-dev mailing list