Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 47576 invoked from network); 17 Apr 2011 16:15:58 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Apr 2011 16:15:58 -0000 Received: (qmail 81951 invoked by uid 500); 17 Apr 2011 16:15:56 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 81926 invoked by uid 500); 17 Apr 2011 16:15:56 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 81918 invoked by uid 99); 17 Apr 2011 16:15:56 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 16:15:56 +0000 X-ASF-Spam-Status: No, hits=2.2 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (nike.apache.org: 209.85.214.44 is neither permitted nor denied by domain of oberman@civicscience.com) Received: from [209.85.214.44] (HELO mail-bw0-f44.google.com) (209.85.214.44) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 17 Apr 2011 16:15:49 +0000 Received: by bwz13 with SMTP id 13so3870269bwz.31 for ; Sun, 17 Apr 2011 09:15:28 -0700 (PDT) Received: by 10.205.36.65 with SMTP id sz1mr3302183bkb.74.1303056928210; Sun, 17 Apr 2011 09:15:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.118.197 with HTTP; Sun, 17 Apr 2011 09:15:08 -0700 (PDT) X-Originating-IP: [24.131.19.240] In-Reply-To: References: <8747B84D-8AAB-4DDB-A4B5-215EC7962B03@cmu.edu> <64E44C90-0AAB-40E3-B972-FD94C3D6C02F@cmu.edu> <86974EFE-F65B-47DB-86E7-0BDEB24E65FB@cmu.edu> <1288264559807268502@unknownmsgid> From: William Oberman Date: Sun, 17 Apr 2011 12:15:08 -0400 Message-ID: Subject: Re: Consistency model To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec52d4cfd54001604a11f95f2 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec52d4cfd54001604a11f95f2 Content-Type: text/plain; charset=ISO-8859-1 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 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" > 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 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) oberman@civicscience.com --bcaec52d4cfd54001604a11f95f2 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Cool, that is exactly what I was thinking/expecting, and I feel better abou= t the assumptions I've used in my refactor to move from MySQL -> cas= sandra. =A0

I basically gave up on trying to force my co= de to assume (even at quorum):=A0
-read value(s) for key from cassandra
-update/add/delete col= umns 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 w= ould be equal to the new value(s). =A0But I do assume I read value(s) >= =3D the new value(s). Of course, in another process, I don't assume any= thing (e.g. my application is ok reading the same state A in two processes = and updating the state to either B or C. =A0I figured that's the best a= distributed algorithm could do without a "test and set" operatio= n).

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 a= t quorum, which would have been bad for me. =A0But this thread is not sayin= g that, so I'm still happy with cassandra :-)=A0

will

On Sun, Apr= 17, 2011 at 11:24 AM, Milind Parikh <milindparikh@gmail.com> wrote:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex;">

William
The issue is regarding whether you will see A or B; with any guarantee of e= ither. The discussion implies no; until the QW is complete.

/***********************
sent from my android...please pardon occasional typos as I respond @ the sp= eed of thought
************************/

On Apr 17, 2011 7:= 48 AM, "William Oberman" <oberman@civicscience.com> wrote:

I'm pretty new to all o= f 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:<= /div>
1. I'm trying to mutate the state of a key's column from A to B fro= m 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. =A0But, I wanted to get to state B, an= d if #1 retries until guaranteed success, do I care if I set B earlier than= I expected? =A0I'm thinking no.=A0

I guess in terms of distributed algorithms/reasoning ab= out systems, I'm feeling ok with this level of guarantee (again, given = the failed write tells the client code of the undefined state).=A0



On Apr 17, 2011, at 10:10 AM, James Cipar <jcipar@cmu.edu> wrote:<= br>
> I'm pretty new to Cassandra, ...

=




--
Will Oberman
Civic S= cience, Inc.
3030 Penn Avenue., First Floor
Pittsburgh, PA 15201
(= M) 412-480-7835
(E) oberman@= civicscience.com
--bcaec52d4cfd54001604a11f95f2--