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.


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)?