James: I feel like I understand what's going on in your code now based on this discussion, and I'm ok with the fact that DURING a QW you can get "transitional" results from a QR in another process (or either the before or after state of the QW). But once the QW succeeds, you must get the new value. That's what we're all saying now, right? In your "read, read, read" case, all 3 reads are happening during a QW, and some of them see the "before" and some of them see the "after" (that's why I specifically said single threaded, not because it's a single thread per se, but because a single thread can't read during a write by definition).
will On Sun, Apr 17, 2011 at 1:27 PM, Milind Parikh <milindpar...@gmail.com>wrote: > Same process or not: only successful QR reads after successful QW will > behave with this guarantee. > > /*********************** > sent from my android...please pardon occasional typos as I respond @ the > speed of thought > ************************/ > > On Apr 17, 2011 10:04 AM, "James Cipar" <jci...@cmu.edu> wrote: > > > For a second, I thought this thread was saying I could see value(s) < new > value(s) within the same... > That's exactly what I'm saying. Within a single process I see this > behavior, when reading with consistency_level=QUORUM > > Read value 1 > Read value 2 > Read value 1 # uh oh! we've gone backwards > > > > > > On Apr 17, 2011, at 12:15 PM, William Oberman wrote: > > > Cool, that is exactly what I was thinkin... > > -- Will Oberman Civic Science, Inc. 3030 Penn Avenue., First Floor Pittsburgh, PA 15201 (M) 412-480-7835 (E) ober...@civicscience.com
