Re: QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-27 Thread aaron morton
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

Re: QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-27 Thread Philip O'Toole
Cool - thanks to all for the replies. I believe I have what I need now. Philip On 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

Re: QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-25 Thread Philip O'Toole
Hi Derek -- thanks. More inline. On Fri, Aug 24, 2012 at 11:52:49PM -0600, Derek Williams wrote: On Fri, Aug 24, 2012 at 10:55 PM, Philip O'Toole phi...@loggly.com wrote: But consider this. Say I have a replication factor of 3. I request a QUORUM write, and it fails because the write only

Re: QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-25 Thread Guillermo Winkler
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

Re: QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-25 Thread Russell Haering
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

Re: QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-25 Thread Guillermo Winkler
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

QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-24 Thread Philip O'Toole
Hello -- perhaps someone could provide me some clarification about this. From: http://www.datastax.com/docs/1.1/dml/data_consistency#data-consistency If consistency is top priority, you can ensure that a read will always reflect the most recent write by using the following formula:

Re: QUORUM writes, QUORUM reads -- and eventual consistency

2012-08-24 Thread Derek Williams
On Fri, Aug 24, 2012 at 10:55 PM, Philip O'Toole phi...@loggly.com wrote: But consider this. Say I have a replication factor of 3. I request a QUORUM write, and it fails because the write only reaches 1 node. Perhaps there is a temporary partition in my cluster. Now, asynchronously, a