> Doesn't this mean that the read does not "reflect the most recent write"? Yes. A write that fails is not a write.
> If it were to have read the newer data from the 1 node and then afterwards > read the old data from the other 2 then there is a consistency problem, but > in the example you give the second reader seems to still have a consistent > view. In the scenario of a TimedOutException for a write that is entirely possible. The write is not considered to be successful at the CL requested. So R + W > N does not hold for that datum. When in doubt, ask Werner… when R + W > N we have strong consistency… "Strong consistency. After the update completes, any subsequent access (by A, B, or C) will return the updated value." when R + W <= N we have weak / eventual consistency… "*Eventual consistency. This is a specific form of weak consistency; the storage system guarantees that if no new updates are made to the object, eventually *all* accesses will return the last updated value." http://queue.acm.org/detail.cfm?id=1466448 (emphasis added) In C* this may mean HH or RR or repair or standard CL checks kicking in to make the second read return the "correct" consistent value. > Isn't it cheaper to retry the mutation on _any exception_ than to have a > transaction in place for the majority of non failing writes? Yes (with the counter exception). if you get an UnavailableException it's from the point of view of the coordinator. it may be the case that the coordinator is isolated and all the other nodes are UP and happy. Hope that helps. ----------------- Aaron Morton Freelance Developer @aaronmorton http://www.thelastpickle.com On 26/08/2012, at 5:03 AM, Guillermo Winkler <gwink...@inconcertcc.com> wrote: > Isn't it cheaper to retry the mutation on _any exception_ than to have a > transaction in place for the majority of non failing writes? > > The special case to be considered is obviously counters which are not > idempotent > > https://issues.apache.org/jira/browse/CASSANDRA-2495 > > > > On Sat, Aug 25, 2012 at 4:38 AM, Russell Haering <russellhaer...@gmail.com> > wrote: > 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. >
