So unless you re-try the write, the previous stale write stays on the other two nodes? Would a read repair fix this eventually?
On Thu, Apr 8, 2010 at 11:36 AM, Avinash Lakshman < avinash.laksh...@gmail.com> wrote: > 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)? >> > >
