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