<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<div class="moz-cite-prefix">Hi all,<br>
<br>
<meta charset="utf-8">
with Pedro we have been reasoning on the integration of TO-based
replication protocols, and a few questions popped out.<br>
<br>
We may be missing something here, but it seems that the current
NBST implementation is still not providing support for pending
transactions, namely transactions that are prepared but not yet
committed at the time in which the node receives a state transfer
request. We have tried to figure out how you plan to do this by
checking the design document:<br>
<br>
<a class="moz-txt-link-freetext" href="https://community.jboss.org/wiki/Non-BlockingStateTransferV2">https://community.jboss.org/wiki/Non-BlockingStateTransferV2</a><br>
<br>
but we still have some doubts. The relevant extract seems to be
the following:<br>
<br>
1.3 For new segments, it asks one of the current owners (the
donor) for the transactions and locks.<br>
1.4 The donor only replies with the transactions and locks
after it has installed the new toplogy. We need this to make sure
a proper pending CH is also installed on the donor and request
forwarding to the new pending owners is in place (forwarding is
explained in request handling section).<br>
1.5 The transactions and locks are applied on acceptor.<br>
1.6 The acceptor requests new data segments from donor
asynchronously.<br>
1.7 Unblock all incoming commands. We are now prepared to
process commands although some data segments are still flowing in.<br>
<br>
In point 1.7, you say that you can already process commands for
data segments that a node has not received yet. However, if the
command is, say, a prepare for a key in a missing data segment and
the transaction is requesting a validation (write-skew check), you
would still need to block as you need the most updated data
version to validate it. Are we getting it right?<br>
<br>
Also, it seems that point 1.5 has not been coded yet. We are
asking this, as these functionalities are likely to be useful also
for the NBST version used by TO-based replication protocols. Thus,
it'd probably be better to wait for these parts to be stable and
re-use them, instead than implementing them from scratch and
end-up possibly with conflicting/incompatible implementations.
When do you plan to have this functionality implemented?<br>
<br>
Finally, I wanted to point out that Roberto and Sebastiano have
been thinking about an alternative version of the NBST, which
should further reduce the blocking time of transactions. They're
currently still at the design stage, and are working to prepare a
document that we would like to share with you to get
feedback/comments etc. We plan to have a draft of the algorithm by
Sept. 20.<br>
<br>
Cheers,<br>
<br>
Paolo<br>
<br>
PS: I'll be travelling starting tomorrow and during next week, so
I may not be responding to emails very quickly.<br>
<br>
<br>
On 7/25/12 12:16 PM, Dan Berindei wrote:<br>
</div>
<blockquote
cite="mid:CA+nfvwReFe-y9NSOKpCT-dQycqC1jXECHqEG=b4HM2MZHRX5ng@mail.gmail.com"
type="cite">Sounds good to me, we should have a little more
breathing room after the NBST alpha to look at the state transfer
integration.<br>
<br>
Cheers<br>
Dan<br>
<br>
<br>
<div class="gmail_quote">On Tue, Jul 24, 2012 at 6:08 PM, Mircea
Markus <span dir="ltr"><<a moz-do-not-send="true"
href="mailto:mircea.markus@jboss.com" target="_blank">mircea.markus@jboss.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0
.8ex;border-left:1px #ccc solid;padding-left:1ex">
<div style="word-wrap:break-word">Hi guys,
<div><br>
</div>
<div>I've just had a chat with the CloudTM team(CC) around
the integration of TOB/TOA[1] into Infinispan. Here are
some points:</div>
<div>- the TOB and TOA code has been reviewed in detail by
us. The only part missing is the state transfer
integration</div>
<div>- there's not a lot of sense in integrating TOB/TOM
over the existing state transfer as we would not back port
that to 5.1 and it would be dropped in 5.2</div>
<div>- CloudTM would rebase the TOB/TOA work on top of the
alpha NBST[2](ATM planned at the end of next week/3 Aug)
and we'll integrate that </div>
<div>- first releases of the TOB/TOA would be marked as
experimental in 5.2 </div>
<div><br>
</div>
<div>How does that sound?</div>
<div><br>
</div>
<div>Cheers,</div>
<div>Mircea</div>
<div><br>
</div>
<div>[1] TOA used to be referred to as TOM (M from
multicast). In JGroups terminology that's an Anycast, so
we decided to be consistent with that and use TOAnycast.</div>
<div>[2] <a moz-do-not-send="true"
href="https://community.jboss.org/wiki/Non-blockingStateTransfer"
target="_blank">https://community.jboss.org/wiki/Non-blockingStateTransfer</a></div>
</div>
<br>
_______________________________________________<br>
infinispan-dev mailing list<br>
<a moz-do-not-send="true"
href="mailto:infinispan-dev@lists.jboss.org">infinispan-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
href="https://lists.jboss.org/mailman/listinfo/infinispan-dev"
target="_blank">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a><br>
</blockquote>
</div>
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
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>