<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 9/15/11 2:51 PM, Manik Surtani wrote:
<blockquote
cite="mid:62DED0D0-6511-40D5-BD4A-97062F803EBA@jboss.org"
type="cite"><br>
<div>
<div>On 15 Sep 2011, at 14:44, Paolo Romano wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span"
style="border-collapse: separate; font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; ">Concerning costs. For option 2),
the prepare message should piggyback<span
class="Apple-converted-space"> </span><br>
the version identifiers of *each* data item that needs to be
write-skew<span class="Apple-converted-space"> </span><br>
checked...which may lead to big messages, if you needed to
test a lot of<span class="Apple-converted-space"> </span><br>
data items. But the ws-check is done only on the data items
that are<span class="Apple-converted-space"> </span><br>
both read and written within the same xact. So I'd expect
that normally<span class="Apple-converted-space"> </span><br>
just a few keys would need to be write-skew checked (at
least this would<span class="Apple-converted-space"> </span><br>
be the case for the wide majority of DBMS/STM benchmarks
I've been using<span class="Apple-converted-space"> </span><br>
so far). Therefore I would not be too concerned with this
issue.</span></blockquote>
<br>
</div>
<div>True, but if a vector clock is used as the underlying version
scheme, then the updating node would need to send across its
local clock for each data item, regardless of whether a ws-check
is needed for that data item or not. Correct?</div>
</blockquote>
In fact, my answer was targeting the non-eventual consistency case.<br>
<br>
I don't know exactly what's the algorithm you've in your mind for
eventual consistency, thus I may be missing something here... but if
the updating node (say node i) increases its node clock (say to
value v) when one of its transactions commits, then the i-th entry
of the vector clock of *every* updated data item could be set to the
same value, namely v. So why not sending v only once? <br>
<br>
Do you want to increase the value stored in the i-th entry of each
data item updated by a committing transaction independently (i.e.
data_item.VC[i]=data_item.VC[i]+1 instead of
data_item.VC[i]=++Node_clock_at_i)?<br>
<br>
P<br>
</body>
</html>