[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