Re: [infinispan-dev] [Cloudtm-discussion] Primary-Backup replication scheme in Infinispan

well, trying to make a very long story (probably too) short one may say that: - 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 (http://research.microsoft.com/apps/pubs/default.aspx?id=64636), one can enforce atomicity also in eventually synchronous systems (tolerating f faults out of 2f+1 replicas). - 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: http://en.wikipedia.org/wiki/Split-brain_(Computing) ). Unsurprisingly, also for PB, it is also possible to design (more expensive) variants working in partially synchronous systems. An example is Vertical Paxos (research.microsoft.com/pubs/80907/podc09v6.pdf). Or assuming virtual synchrony (http://en.wikipedia.org/wiki/Virtual_synchrony), by propagating the primary's updates via uniform reliable broadcast (also called safe delivery in virtual synchrony's gergon,http://www.cs.huji.ac.il/labs/transis/lab-projects/guide/chap3.html#safe). 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 (http://en.wikipedia.org/wiki/Paxos_algorithm#Multi-Paxos). 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.