<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi Manik, <br>
<br>
in order to provide correct answers to your questions, I want to ask
you the following:<br>
<br>
- Why do you say that the current MVCC implementation is
non-genuine? I think that for any transaction T, only the sites that
replicate the data items read/written by T exchange messages during
the execution of T and in order to decide the final outcome of T. Is
it correct?<br>
<br>
- About JTA semantics, what do you mean by the term "full"? During
the integration of GMU, we have not changed the way a transaction
was already managed in Infinispan (e.g. 2-PC, interaction between
Transaction Manager and XAResource), so I think that the answer is
yes. But since I have not a deep knowledge about JTA specification,
maybe there is some aspect that I have not considered.<br>
<br>
<br>
Thank you for your feedback!<br>
<br>
<br>
Cheers<br>
<br>
Sebastiano<br>
<br>
<blockquote
cite="mid:F8A3EB69-07BD-41B2-A032-1F325632B9CE@jboss.org"
type="cite">This is very interesting, Paolo. In terms of numbers
of RPC, how does this compare with a classic, non-genuine MVCC we
currently have in Infinispan? I presume you still support full
JTA semantics over GMU?
<div><br>
</div>
<div>Cheers</div>
<div>Manik</div>
<div><br>
<div>
<div><br>
</div>
<br class="Apple-interchange-newline">
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<div bgcolor="#FFFFFF" text="#000000">
<div class="moz-text-flowed" style="font-family:
-moz-fixed; font-size: 12px;" lang="x-western">Hi, <br>
<br>
within the context Cloud-TM project we have developed a
new partial replication algorithm (corresponding to
distribution mode of Infinispan) that guarantees
serializability in a very scalable fashion. We have
called the algorithm GMU, Genuine Multiversion Update
Serializability, and we've integrated it into Infinispan
(5.0.0). <br>
<br>
The source code is available on github: <br>
<br>
<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://github.com/cloudtm/infinispan-5.0.0.SERIALIZABLE">http://github.com/cloudtm/infinispan-5.0.0.SERIALIZABLE</a>
<br>
<br>
GMU's key features are: <br>
<br>
1. unlike any other partial replication protocol we are
aware of, GMU is the first distributed multi-versioned
based partial replication protocol that does not rely on
a single global clock in order to determine consistent
snapshots. Conversely, the protocol guarantees to
involve only the nodes that maintain data accessed by a
committing transaction T (a property that is known in
literature as "genuineness"). This is a property that is
crucial, in our opinion, to achieve high scalability. <br>
<br>
2. read-only tranasctions are never aborted, and do not
need to be validated at commit time, making them very
fast. Read-only transactions are guaranteed to observe a
consistent snapshot of the data using a novel mechanism
based on vector clocks. Note that in order to achieve
this results we integrated in ISPN a multiversion
concurrency control, very similar to the one used in
PostgreSQL or JVSTM, that maintains multiple data item
versions tagged with scalars per each key. <br>
<br>
3. The consistency guarantees ensured by GMU are a
variant of classic 1-Copy-Serialiability (1CS), and,
more precisely, "extended update serializable" (EUS).
You can check the tech. report in attach for more
details on this, but, roughly speaking, US guarantees
that update transactions execute according to 1CS.
Concurrent read-only transactions, instead, may observe
the updates generated by two <b class="moz-txt-star"><span
class="moz-txt-tag">*</span>non-conflicting<span
class="moz-txt-tag">*</span></b> update transactions
in different order. <br>
In practice, we could not think of any realistic
application for which the schedules admitted by US would
represent an issue, which leads us to argue that US is,
in practical settings, as good as 1CS, but brings the
key advantage of allowing way more scalable (genuine)
implementations. <br>
<br>
We have evaluated GMU performance using up to 20
physical machines in our in-house cluster, and in 40 VMs
in the FutureGrid (and we are currently trying to use
more VMs in FutureGrid to see if we can make it scale up
to hundreds of machines... we'll keep you posted on
this!) with the YCSB (<a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="https://github.com/brianfrankcooper/YCSB/wiki">https://github.com/brianfrankcooper/YCSB/wiki</a>)
and TPC-C benchmarks. <br>
<br>
Our experimental results show that in low conflict
scenarios, the protocol performs as good as the existing
Repeatable Read implementation... and actually, in some
scenarios, even slightly better, given that GMU spares
the cost of saving the values read in the transactional
context, unlike the existing Repeatable Read
implementation. <br>
<br>
In high contention scenarios, GMU does pay a higher toll
in terms of aborts, but it still drastically outperform
classic non-genuine MVCC implementations as the size of
the system grows. Also, we've a bunch of ideas on how to
improve GMU performance in high contention scenarios...
but that's another story! <span class="moz-smiley-s3"
title=";-)"></span> <br>
<br>
You find the technical report at this url:<br>
<br>
<a moz-do-not-send="true" class="moz-txt-link-freetext"
href="http://www.inesc-id.pt/ficheiros/publicacoes/7549.pdf">http://www.inesc-id.pt/ficheiros/publicacoes/7549.pdf</a><br>
<br>
Comments are more than welcome of course! <br>
<br>
Cheers, <br>
<br>
Paolo <br>
<br>
-- <br>
<br>
Paolo Romano, PhD<br>
Coordinator of the Cloud-TM ICT FP7 Project (<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="http://www.cloudtm.eu/">www.cloudtm.eu</a>)<br>
Senior Researcher @ INESC-ID (<a moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="http://www.inesc-id.pt/">www.inesc-id.pt</a>)<br>
Invited Professor @ Instituto Superior Tecnico (<a
moz-do-not-send="true"
class="moz-txt-link-abbreviated"
href="http://www.ist.utl.pt/">www.ist.utl.pt</a>)<br>
Rua Alves Redol, 9<br>
1000-059, Lisbon Portugal<br>
Tel. + 351 21 3100300<br>
Fax + 351 21 3145843<br>
Webpage <a moz-do-not-send="true"
class="moz-txt-link-freetext"
href="http://www.gsd.inesc-id.pt/%7Eromanop">http://www.gsd.inesc-id.pt/~romanop</a><br>
</div>
</div>
_______________________________________________<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 class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/infinispan-dev">https://lists.jboss.org/mailman/listinfo/infinispan-dev</a></blockquote>
</div>
<br>
<div apple-content-edited="true">
<span class="Apple-style-span" style="border-collapse:
separate; color: rgb(0, 0, 0); font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: 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; ">
<div>
<div>--</div>
<div>Manik Surtani</div>
<div><a moz-do-not-send="true"
href="mailto:manik@jboss.org">manik@jboss.org</a></div>
<div><a moz-do-not-send="true"
href="http://twitter.com/maniksurtani">twitter.com/maniksurtani</a></div>
<div><br>
</div>
<div>Lead, Infinispan</div>
<div><a moz-do-not-send="true"
href="http://www.infinispan.org">http://www.infinispan.org</a></div>
<div><br>
</div>
</div>
</span><br class="Apple-interchange-newline">
</div>
<br>
</div>
<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>