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. >
