This is my understanding, others disagree. Sequential consistency: each program's order of reads is preserved Linearizability: each program's order of all reads as well as writes is preserved
Assume a single process is making reads and writes to the same partition key, the replication factor is 3, and the process is submitting its own timestamps so there is no clock drift. TS1: Commit value A to R1 and R2: success TS2: Read value from R2 and R3: A TS3: Commit value B to R1 only: E (timeout error) TS4: Read value from R2 and R3: A TS5: Read value from R1 and R2: B The valid linearizations were either A-E-A or A-E-B, not A-E-A-B. There are other linearizability violations without failures, as well as violations of sequential consistency, if multiple clocks are used for writing to the same partition key by different processes or different coordinators. Evan On Sat, Oct 18, 2014 at 9:19 AM, DuyHai Doan <doanduy...@gmail.com> wrote: > Hello Evan > > Why, in a scenario of resurrections of unacknowledged writes, don't we get > linearizability ? Can you give more detailed explanation on such scenario ? > > @Oliver: true, the formal definition of linearizability is not related to > isolation. My bad. And for your question "What does Cassandra do in the case > of inconsistent reads? Wait or report failure? I could not find that one in > the docs. ", if you're reading at CL >= QUORUM, Cassandra will repair the > data before sending the good result (good = data with latest timestamp, last > write win rule) to the client. > > Regards > > On Thu, Oct 16, 2014 at 7:16 PM, Evan Weaver <e...@fauna.org> wrote: >> >> Quorum reads and writes in Cassandra guarantee sequential consistency. >> The reason this doesn't satisfy linearizability is because >> resurrections of unacknowledged writes can occur. A read of a >> half-committed write will trigger synchronous read repair and the >> order will be stable from that point forward. >> >> Isolation is an unrelated issue. >> >> Evan >> >> On Wed, Oct 15, 2014 at 4:45 PM, Timmy Turner <timm.t...@gmail.com> wrote: >> > Cassandra in general can't provide guarantee any ordering of the >> > executed >> > queries, since nodes may fail or rejoin the in arbitrary points in time. >> > >> > But why can't it provide ordering for queries run at at least the quorum >> > level? Given that none of the updates get lost, why would order still an >> > issue? >> > >> > Can you maybe illustrate a scenario which shows how/where the order >> > would >> > get lost if writes and reads always occurred with quorum consistency? > >
