<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 12/9/11 4:19 PM, Manik Surtani wrote:
<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? </blockquote>
Same number of round. We're using plain 2PC in this case, but we
could plug-in total-order multi-cast in future to avoid deadlocks.<br>
<blockquote
cite="mid:F8A3EB69-07BD-41B2-A032-1F325632B9CE@jboss.org"
type="cite"> I presume you still support full JTA semantics over
GMU?</blockquote>
I presume it too ;-)<br>
<br>
Cheers,<br>
<br>
Paolo<br>
<blockquote
cite="mid:F8A3EB69-07BD-41B2-A032-1F325632B9CE@jboss.org"
type="cite">
<div><br>
</div>
<div>Cheers</div>
<div>Manik</div>
<div><br>
<div>
<div>On 29 Nov 2011, at 13:11, Paolo Romano wrote:</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>