<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>On 25 May 2011, at 00:08, Paolo Romano wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite">
<div text="#000000" bgcolor="#ffffff">
I agree with you that lock contention has a dramatic effect on
performance of transactional's workload and these ideas are
interesting.<br>
<br>
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:<br>
<br>
N3: receives T1, acquires lock on c, reply positively to the prepare
to N1<br>
N3: receives T2, blocks on lock acquisition on c<br>
N1: receives positive reply on reply for T1, broadcasts commit
message for T1 to N3, N4 .... but the message to N4 gets delayed ...<br>
N3: receives commit message for T1, writes back c<-T1, unblocks
T2, replies positively for T2' s prepare to N2<br>
N2: receives positive reply on reply for T2, broadcasts commit msg
for T2 to N3, N4<br>
N4: receives commit message for T2 (before that for T1), writes back
c<-T2<br>
N4: receives commit message for T1, writes back c<-T1,<br>
N3: receives commit message for T2, writes back c<-T2</div></blockquote><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
<br>
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).<br>
<br>
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!).<br></div></blockquote>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.<br><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
<br>
Cheers,<br>
<br>
Paolo<br>
<br>
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.<br></div></blockquote>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.</div><div><blockquote type="cite"><div text="#000000" bgcolor="#ffffff">
<br>
PPS: I'm cc-ing cloudtm-discussion as I believe that this thread may
be of interest also for this project.<br>
[1] <a class="moz-txt-link-freetext" href="http://community.jboss.org/wiki/PossibleLockingImprovements">http://community.jboss.org/wiki/PossibleLockingImprovements</a></div></blockquote><div><br></div><div>Thanks for the very good point around consistency!</div><br></div><br></body></html>