cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Evan Weaver <>
Subject Re: Why is Quorum not sufficient for Linearization?
Date Sat, 18 Oct 2014 22:11:10 GMT
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.


On Sat, Oct 18, 2014 at 9:19 AM, DuyHai Doan <> 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 <> 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 <> 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?

View raw message