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 reaches 1 node. Perhaps > > there is a temporary partition in my cluster. Now, asynchronously, a > > different reader performs a QUORUM read of the same cluster and just before > > it issues the read, the partition is resolved. The quorum read is satisfied > > by the two nodes that have *not* received the latest write (yet). Doesn't > > this mean that the read does not "reflect the most recent write"? I realise > > this is very unlikely to happen in practise, but I want to be sure I > > understand all this. > > > > Others might disagree, but as long as the view from the second reader > remains consistent then I see no problem. 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. Trying to guarantee that all > clients will have the same view at all times is working against Cassandra's > strengths.
I can agree with this interpretation, and that it is a reasonable interpretation of "consistency". > > Where quorum reads and writes are most important is when consistency is > required from the point of view of a single client. A single client is exactly what I am thinking about. > > This is besides the point that the documentation states that the sum of the > nodes written to and read from needs to be greater then the replication > factor for the statement to be true. In your example only 1 node was > written to, when 2 were required to guarantee consistency. The intent to do > a quorum write is not the same as actually doing one. 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. > > -- > Derek Williams -- Philip O'Toole Senior Developer Loggly, Inc. San Francisco, CA
