"what is the fundamental difference between the standard replication protocol and Paxos that prevents us from implementing a 2-pc on top of the standard protocol?"
--> for a more detailed description of Paxos, look here: http://www.slideshare.net/doanduyhai/distributed-algorithms-for-big-data-geecon/41 Long story short, when there is an ongoing operation (INSERT, UPDATE, DELETE, ...) on a particular partition key with Paxos, any other concurrent operation on the same partition key will have to wait until the ongoing operation commits. If the ongoing operation is validated by Paxos but fails before being able to commit (after the accept phase in the diagram), then any subsequent operation on this partition key will commit this stalled operation before starting its own. On Mon, Aug 3, 2015 at 4:30 AM, Yang <teddyyyy...@gmail.com> wrote: > this link > http://www.datastax.com/dev/blog/lightweight-transactions-in-cassandra-2-0 > talks about linearizable consistency and lightweight transactions. > > but I am still not completely following it , just based on the article > itself. > > the standard replication protocol in Cassandra does establish a total > order (based on client TS, though that can be wrong/unfair), so in the > case of the example mentioned in the article "if 2 people try to create the > same account', yes if both of them just brute-force write, ultimately we > will have one winner, who provided the higher TS (this is done consistently > across all replicas). > > what really matters in the above situation is the ability to group the 2 > operations "check existing account" and "create account" together and run > them in an atomic way. so we need something like a 2-phase commit. > > I guess what is not clear from that article is , what is the fundamental > difference between the standard replication protocol and Paxos that > prevents us from implementing a 2-pc on top of the standard protocol? > > Thanks! > yang >
