<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body 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<br>
<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>
<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>
<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><br>
<br>
On 5/24/11 10:36 PM, Mircea Markus wrote:
<blockquote
cite="mid:4C1E8BEE-077D-4346-9052-CB45E19DFA7C@jboss.com"
type="cite">Hi,
<div><br>
</div>
<div>This is re: <a moz-do-not-send="true"
href="http://community.jboss.org/wiki/PossibleLockingImprovements">http://community.jboss.org/wiki/PossibleLockingImprovements</a></div>
<div><br>
</div>
<div>I've created JIRAs for the locking optimisations as follows:</div>
<div><br>
</div>
<div>#1: <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-1131">https://issues.jboss.org/browse/ISPN-1131</a></div>
<div>#2: this seems to be just a particular case of #4 </div>
<div>#3: <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-1132">https://issues.jboss.org/browse/ISPN-1132</a></div>
<div>#4: <a moz-do-not-send="true"
href="https://issues.jboss.org/browse/ISPN-1137">https://issues.jboss.org/browse/ISPN-1137</a></div>
<div>#5: I think this is pretty much the same thing as #4, waiting
for Sanne to confirm that. </div>
<div><br>
</div>
<div>Each JIRA also contains the design I have in mind for
implementing them.</div>
<div>I do think this will improve the transactional throughput
*significantly*, so any feedback much appreciated.</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Mircea</div>
<pre wrap="">
<fieldset class="mimeAttachmentHeader"></fieldset>
_______________________________________________
infinispan-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></pre>
</blockquote>
<br>
</body>
</html>