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 <jdu...@gmail.com> wrote: > On Thu, Apr 8, 2010 at 7:16 AM, Gary Dusbabek <gdusba...@gmail.com> wrote: > > On Thu, Apr 8, 2010 at 02:55, Paul Prescod <p...@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)? >
