The "issue" is that it is possible for a quorum write to return an error, but for the result of the write to still be reflected in the view seen by the client. There is really no performant way around this (although reading at ALL can make it much less frequent). Guaranteeing complete success or failure would (barring a creative solution I'm unaware of) require a transactional commit of some sort across the replica nodes for the key being written to. The performance tradeoff might be desirable under some circumstances, but if this is a requirement you should probably look at other databases.
Some good rules to play by (someone correct me if these aren't 100% true): 1. For writes to a single key, an UnavailableException means the write failed totally (clients will never see the data you wrote) 2. For writes to a single key, a TimedOutException means you cannot know whether the write succeeded or failed 3. For writes to multiple keys, either an UnavailableException or a TimedOutException means you cannot know whether the write succeeded or failed. -Russell On Sat, Aug 25, 2012 at 12:17 AM, Guillermo Winkler <gwink...@inconcertcc.com> wrote: > Hi Philip, > > From http://wiki.apache.org/cassandra/ArchitectureOverview > > Quorum write: blocks until quorum is reached > > By my understanding if you _did_ a quorum write it means it successfully > completed. > > Guille > > >> I *think* we're saying the same thing here. The addition of the word >> "successful" (or something more suitable) would make the documentation more >> precise, not less.
