> For a second, I thought this thread was saying I could see value(s) < new > value(s) within the same process on the second read at quorum
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 thinking/expecting, and I feel better about > the assumptions I've used in my refactor to move from MySQL -> cassandra. > > I basically gave up on trying to force my code to assume (even at quorum): > -read value(s) for key from cassandra > -update/add/delete columns for key in memory based on value(s) > -write new value(s) for key to cassandra > That the next read for key in the same process would be equal to the new > value(s). But I do assume I read value(s) >= the new value(s). Of course, in > another process, I don't assume anything (e.g. my application is ok reading > the same state A in two processes and updating the state to either B or C. I > figured that's the best a distributed algorithm could do without a "test and > set" operation). > > For a second, I thought this thread was saying I could see value(s) < new > value(s) within the same process on the second read at quorum, which would > have been bad for me. But this thread is not saying that, so I'm still happy > with cassandra :-) > > will > > On Sun, Apr 17, 2011 at 11:24 AM, Milind Parikh <milindpar...@gmail.com> > wrote: > William > The issue is regarding whether you will see A or B; with any guarantee of > either. The discussion implies no; until the QW is complete. > > /*********************** > sent from my android...please pardon occasional typos as I respond @ the > speed of thought > ************************/ > > >> On Apr 17, 2011 7:48 AM, "William Oberman" <ober...@civicscience.com> wrote: >> >> I'm pretty new to all of this, and I'm in the process of building my mental >> model of Cassandra, but I'm still feeling better about this thread. The way >> I figure it: >> 1. I'm trying to mutate the state of a key's column from A to B from a >> thread somewhere (quorum) >> 2. I'm trying to read the state of a key from a thread somewhere else >> (quorum) >> >> If #1 succeeds I'm guaranteed to see B. If #1 fails (with an exception) I'll >> see either A or B. I think I was concerned about that, and wanted to see A >> in #2 until success in #1. But, I wanted to get to state B, and if #1 >> retries until guaranteed success, do I care if I set B earlier than I >> expected? I'm thinking no. >> >> I guess in terms of distributed algorithms/reasoning about systems, I'm >> feeling ok with this level of guarantee (again, given the failed write tells >> the client code of the undefined state). >> >> >> >> On Apr 17, 2011, at 10:10 AM, James Cipar <jci...@cmu.edu> wrote: >> >> > I'm pretty new to Cassandra, ... >> > > > > > -- > Will Oberman > Civic Science, Inc. > 3030 Penn Avenue., First Floor > Pittsburgh, PA 15201 > (M) 412-480-7835 > (E) ober...@civicscience.com
