<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; ">Yeah, I know all this ... recall my PhD was on transactions and replication :-)<div><br></div><div>You can tolerate partitions if you add weighted voting schemes to the group mechanism so that only a primary in the majority partition can do any work.</div><div><br></div><div>Mark.</div><div><br></div><div><br><div><div>On 18 Feb 2011, at 00:59, 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-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; ">well, trying to make a very long story (probably too) short one may say that:<br><br>- in an asynchronous system (even if augmented with eventually perfect failure detection), classic 2PC blocks upon coordinator crashes. This, pragmatically, forces to heuristic decisions that may lead to atomicity violations. Using more expensive commit protocols, such as Paxos Commit (<a class="moz-txt-link-freetext" href="http://research.microsoft.com/apps/pubs/default.aspx?id=64636">http://research.microsoft.com/apps/pubs/default.aspx?id=64636</a>), one can enforce atomicity also in eventually synchronous systems (tolerating f faults out of 2f+1 replicas).<span class="Apple-converted-space"> </span><br><br>- With primary backup (PB), in an asynchronous system the issue is the split-brain syndrome (this wiki definition is not the best ever but it's the only I could rapidly find:<span class="Apple-converted-space"> </span><a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Split-brain_(Computing)">http://en.wikipedia.org/wiki/Split-brain_(Computing)</a><span class="Apple-converted-space"> </span>). Unsurprisingly, also for PB, it is also possible to design (more expensive) variants working in partially synchronous systems. An example is Vertical Paxos (<a href="http://research.microsoft.com/pubs/80907/podc09v6.pdf">research.microsoft.com/pubs/80907/podc09v6.pdf</a>). Or assuming virtual synchrony (<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Virtual_synchrony">http://en.wikipedia.org/wiki/Virtual_synchrony</a>), by propagating the primary's updates via uniform reliable broadcast (also called safe delivery in virtual synchrony's gergon,<a class="moz-txt-link-freetext" href="http://www.cs.huji.ac.il/labs/transis/lab-projects/guide/chap3.html#safe">http://www.cs.huji.ac.il/labs/transis/lab-projects/guide/chap3.html#safe</a>). Or, mapping the solution to classic Paxos, by having the role of the primary coincide with that of the leader in the Multi-paxos protocol (<a class="moz-txt-link-freetext" href="http://en.wikipedia.org/wiki/Paxos_algorithm#Multi-Paxos">http://en.wikipedia.org/wiki/Paxos_algorithm#Multi-Paxos</a>).<span class="Apple-converted-space"> </span><br><br>Note that, in an asynchronous system, the PB implementation shown in the plots might violate consistency in case of false failure suspicions of the primary, just like the current Infinispan's 2PC based replication scheme might do in case of false failure suspicions of the coordinator. So, in terms of required synchrony assumptions, the 2 considered protocols are fairly comparable.</span></blockquote></div><br><div>
<span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: medium; 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; "><span class="Apple-style-span" style="border-collapse: separate; color: rgb(0, 0, 0); font-family: Helvetica; font-size: 12px; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; 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; "><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>---</div><div>Mark Little</div><div><a href="mailto:mlittle@redhat.com">mlittle@redhat.com</a></div><div><br class="webkit-block-placeholder"></div><div>JBoss, by Red Hat</div><div>Registered Address: Red Hat UK Ltd, Amberley Place, 107-111 Peascod Street, Windsor, Berkshire, SI4 1TE, United Kingdom.</div><div>Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Charlie Peters (USA), Matt Parsons (USA) and Brendan Lane (Ireland).</div></div><div><br></div></div></span><br class="Apple-interchange-newline"></span><br class="Apple-interchange-newline">
</div>
<br></div></body></html>