cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Avinash Lakshman <avinash.laksh...@gmail.com>
Subject Re: Write consistency
Date Thu, 08 Apr 2010 15:36:36 GMT
What your describing is a distributed transaction? Generally strong
consistency is always associated with doing transactional writes where you
never see the results of a failed write on a subsequent read no matter what
happens. Cassandra has no notion of rollback. That is why no combination
will give you strong consistency. The idea is you re-try the failed write
and eventually the system would have gotten rid of the previous stale write.

Avinash

On Thu, Apr 8, 2010 at 8:29 AM, Jeremy Dunck <jdunck@gmail.com> wrote:

> On Thu, Apr 8, 2010 at 7:16 AM, Gary Dusbabek <gdusbabek@gmail.com> wrote:
> > On Thu, Apr 8, 2010 at 02:55, Paul Prescod <paul@ayogo.com> wrote:
> >> In this¹ debate, there seemed to be consensus on the following fact:
> >>
> >> "In Cassandra, say you use N=3, W=3 & R=1. Let’s say you managed to
> >> only write to replicas A & B, but not C. In this case Cassandra will
> >> return an error to the application saying the write failed- which is
> >> acceptable given than W=3. But Cassandra does not cleanup/rollback the
> >> writes that happened to A & B."
> >>
> >
> > correct: no rolling back.  Cassandra does go out of its way to make
> > sure the cluster is healthy enough to begin the write though.
>
> I think the general answer here is don't use R=1 if you can't tolerate
> inconsistency?  Still the point of confusion -- if W=3 and the write
> succeeds on 2 nodes but fails the 3rd, the write fails (to the
> updating client), but is the data on the two successful nodes still
> readable (i.e. reading from what was actually a failed write)?
>

Mime
View raw message