Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 0E247619B for ; Fri, 8 Jul 2011 14:23:27 +0000 (UTC) Received: (qmail 46161 invoked by uid 500); 8 Jul 2011 14:23:24 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 46104 invoked by uid 500); 8 Jul 2011 14:23:23 -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 46092 invoked by uid 99); 8 Jul 2011 14:23:23 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jul 2011 14:23:23 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of jeffpk@gmail.com designates 74.125.83.172 as permitted sender) Received: from [74.125.83.172] (HELO mail-pv0-f172.google.com) (74.125.83.172) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 08 Jul 2011 14:23:17 +0000 Received: by pvh18 with SMTP id 18so1633005pvh.31 for ; Fri, 08 Jul 2011 07:22:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=SEJNF9LldZ09y6hmbfcTmxjbaMBz2IS9L1kjfAyyRzs=; b=KktyRE5We0FHLPVyC83L8C/ysaDyaG5V1Zfd4QX+L8fj+HY7gjVPrZFnYC4TkgwoVI NgkX+fWfc2+cHxyx2ZQfStWEENcK5SbAc0H7AdSwWZVm1eoAz41Ymz5uQijTUA1a0i78 3uTJmH+KGw0+WcRuyBrh1p09+Sz4PqRYRyfQw= MIME-Version: 1.0 Received: by 10.68.50.36 with SMTP id z4mr2933696pbn.365.1310134975606; Fri, 08 Jul 2011 07:22:55 -0700 (PDT) Received: by 10.68.44.8 with HTTP; Fri, 8 Jul 2011 07:22:55 -0700 (PDT) In-Reply-To: References: Date: Fri, 8 Jul 2011 10:22:55 -0400 Message-ID: Subject: Re: What does a write lock ? From: Jeffrey Kesselman To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=bcaec543076ed42eba04a78f91f7 X-Virus-Checked: Checked by ClamAV on apache.org --bcaec543076ed42eba04a78f91f7 Content-Type: text/plain; charset=ISO-8859-1 Not quite, its more limited and specific.... The order of operations is all within the Cassandra node server and looks like this this... We have one row, A. Thats the only row being operated on. Client -> submits A' Server does the following: (1) Validate function reads current A (2) Validate function validates A' vs. A (3) If validation succeeds, allows update to A'. My fear/concern is that after 1 and before 3, a second update to A'' comes in and changes the "current" value of A, therefor invalidating my validation check, see? If Cassandra does not guard against this then one possible solution would be to make my own key-to-mutex map in memory, lock the mutex for A's key as a precursor to (1) and release it in a post-update function. But I am always very nervous about inserting locking into a process that wasn't designed with it already in mind... On Fri, Jul 8, 2011 at 8:30 AM, William Oberman wrote: > Questions like this seem to come up a lot: > > http://stackoverflow.com/questions/6033888/cassandra-atomicity-isolation-of-column-updates-on-a-single-row-on-on-single-no > > http://stackoverflow.com/questions/2055037/cassandra-atomic-reads-writes-within-a-single-columnfamily > http://www.mail-archive.com/user@cassandra.apache.org/msg14701.html > > Lets say you read state A (from one key in one CF), you change the data to > A' in your client, and you write A'. Are you worried that someone else > might have changed A to B during this process (making the "new" state a race > between A' and B)? It doesn't sound to me like you are... It sounds to me > like you're worried about a set of columns for the key being in a consistent > state before, during, and after a process. And A -> A' and A -> B will each > be atomic for the key (based on my understanding). But, if A' and B are > changes to a different set of columns, I believe that would interleave, > which itself could be "inconsistent" from your application's point of view. > > > will > > On Thu, Jul 7, 2011 at 11:41 PM, Jeffrey Kesselman wrote: > >> Really, as i lay in the bath thinking nabout it, I concluded what I am >> looking for is a very limited form of Consistency. >> >> Its consistency over a single row on a single node just for the period of >> update. >> >> >> On Thu, Jul 7, 2011 at 10:34 PM, Jeffrey Kesselman wrote: >> >>> Its not really isolation, btw, because we >>> arent talking about anyone seeing an update mid-update. Rather, we >>> are talking about when updates are allowed to occur. >>> >>> Atomicity means that all the updates happen together or they don't happen >>> at all. >>> Isolation means that no results of the update are visible until the >>> entire update operation is complete. >>> >>> This really lies somewhere in the middle of the two concepts. Its part >>> of the results of the combined effects of ACID >>> >>> >>> On Thu, Jul 7, 2011 at 10:27 PM, Jonathan Ellis wrote: >>> >>>> Sounds to me like you're confusing atomicity with isolation. >>>> >>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman >>>> wrote: >>>> > Yup, im even more confused. Lets talk about the model, not the >>>> > implementation. >>>> > AIUI updates to a row are atomic across all columns in that row at >>>> once, >>>> > true? >>>> > If true then the next question is, does the validation happen inside >>>> or >>>> > outside of that guarantee, and is the row guaranteed not to change >>>> between >>>> > validation and update? >>>> > If that is *not* the case then it makes a whole class of solutions to >>>> > synchronization problems fail and puts my larger project >>>> > in serious question. >>>> > >>>> > On Thu, Jul 7, 2011 at 3:43 PM, Yang wrote: >>>> >> >>>> >> no , the memtable is a concurrentskiplistmap >>>> >> >>>> >> insertion can happen in parallel >>>> >> >>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" >>>> wrote: >>>> >> > This has me more confused. >>>> >> > >>>> >> > Does this mean that ALL rows on a given node are only updated >>>> >> > sequentially, >>>> >> > never in parallel? >>>> >> > >>>> >> > On Thu, Jul 7, 2011 at 3:21 PM, Yang >>>> wrote: >>>> >> > >>>> >> >> just to add onto what jonathan said >>>> >> >> >>>> >> >> the columns are immutable . if u overwrite/ reconcile a new obj is >>>> >> >> created and shoved into the memtable >>>> >> >> >>>> >> >> there is a shared lock for all writes though which guard against >>>> an >>>> >> >> exclusive lock on memtable switching/flushing >>>> >> >> On Jul 7, 2011 7:51 AM, "A J" wrote: >>>> >> >> > Does a write lock: >>>> >> >> > 1. Just the columns in question for the specific row in question >>>> ? >>>> >> >> > 2. The full row in question ? >>>> >> >> > 3. The full CF ? >>>> >> >> > >>>> >> >> > I doubt read does any locks. >>>> >> >> > >>>> >> >> > Thanks. >>>> >> >> >>>> >> > >>>> >> > >>>> >> > >>>> >> > -- >>>> >> > It's always darkest just before you are eaten by a grue. >>>> > >>>> > >>>> > >>>> > -- >>>> > It's always darkest just before you are eaten by a grue. >>>> > >>>> >>>> >>>> >>>> -- >>>> Jonathan Ellis >>>> Project Chair, Apache Cassandra >>>> co-founder of DataStax, the source for professional Cassandra support >>>> http://www.datastax.com >>>> >>> >>> >>> >>> -- >>> It's always darkest just before you are eaten by a grue. >>> >> >> >> >> -- >> It's always darkest just before you are eaten by a grue. >> > > > > -- It's always darkest just before you are eaten by a grue. --bcaec543076ed42eba04a78f91f7 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Not quite, its more limited and specific....

The order o= f operations is all within the Cassandra node server and looks like this th= is...

We have one row, A. =A0Thats the only row be= ing=A0operated=A0on.

Client -> submits A'
Server does the f= ollowing:
(1) Validate function reads current A
(2) Val= idate function validates A' vs. A
(3) If validation succeeds,= allows update to A'.

My fear/concern is that after 1 and before 3, a second = update to A'' comes in and changes the "current" value of= A, therefor invalidating my validation=A0check, see?

If Cassandra does not guard against this then one possible solution=A0= would=A0be to make my own key-to-mutex map in memory, lock the mutex for A&= #39;s key as a precursor to (1) and release it in a post-update function. = =A0But I am always very nervous about inserting locking into a process that= wasn't designed with it already in mind...


On Fri, Jul 8, 2011 at 8:30 AM, Wil= liam Oberman <oberman@civicscience.com> wrote:
Questions like this seem to come up a lot:
http://stackoverflow.com/= questions/6033888/cassandra-atomicity-isolation-of-column-updates-on-a-sing= le-row-on-on-single-no

Lets say you read state A= (from one key in one CF), you change the data to A' in your client, an= d you write A'. =A0Are you worried that someone else might have changed= A to B during this process (making the "new" state a race betwee= n A' and B)? =A0It doesn't sound to me like you are... =A0It sounds= to me like you're worried about a set of columns for the key being in = a consistent state before, during, and after a process. =A0And A -> A= 9; and A -> B will each be atomic for the key (based on my understanding= ). =A0But, if A' and B are changes to a different set of columns, I bel= ieve that would interleave, which itself could be "inconsistent" = from your application's point of view. =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 = =A0 =A0 =A0 =A0 =A0 =A0

will
=A0 = =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0
On Thu, Jul 7, 2011 at 11:41 PM, Jeffrey Kesselman <jeffpk@gmail= .com> wrote:
Really, as i lay in the bath=A0thinking=A0na= bout it, I concluded what I am looking for is a very limited form of=A0Cons= istency.

Its=A0consistency=A0over a single row on a single node just = for the period of update.


On Thu, Jul 7, 2011 at 10:34 PM, Jeffrey Kes= selman <jeffpk@gmail.com> wrote:
Its not really isolation, btw, because we arent=A0talking=A0about=A0anyone= =A0seeing an update mid-update. =A0 =A0Rather, we are=A0talking=A0about whe= n updates are allowed to occur.

Atomicity means that all= the updates happen together or they don't happen at all.
Isolation means that no results of the update are visible until the en= tire update operation is complete.

This really lie= s somewhere in the middle of the two concepts. =A0 Its part of the=A0result= s=A0of the combined effects of ACID


On Thu, Jul 7, 2011 at 10:27 P= M, Jonathan Ellis <jbellis@gmail.com> wrote:
Sounds to me like you're confusing atomicity with isolation.

On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <jeffpk@gmail.com> wrote:
> Yup, im even more confused. =A0 =A0Lets=A0talk=A0about the model, not = the
> implementation.
> AIUI=A0updates=A0to a row are atomic across all columns in that row at= once,
> true?
> If true then the next question is, does the validation happen inside o= r
> outside of that=A0guarantee, and is the row=A0guaranteed=A0not to=A0ch= ange between
> validation and update?
> If that is *not* the case then it makes a whole class of=A0solutions= =A0to
> synchronization problems fail and puts my larger project
> in=A0serious=A0question.
>
> On Thu, Jul 7, 2011 at 3:43 PM, Yang <teddyyyy123@gmail.com> wrote:
>>
>> no , the memtable is a concurrentskiplistmap
>>
>> insertion can happen in parallel
>>
>> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <jeffpk@gmail.com> wro= te:
>> > This has me more confused.
>> >
>> > Does this mean that ALL rows on a given node are only updated=
>> > sequentially,
>> > never in parallel?
>> >
>> > On Thu, Jul 7, 2011 at 3:21 PM, Yang <teddyyyy123@gmail.com> wrote:=
>> >
>> >> just to add onto what jonathan said
>> >>
>> >> the columns are immutable . if u overwrite/ reconcile a n= ew obj is
>> >> created and shoved into the memtable
>> >>
>> >> there is a shared lock for all writes though which guard = against an
>> >> exclusive lock on memtable switching/flushing
>> >> On Jul 7, 2011 7:51 AM, "A J" <s5alye@gmail.com> wrote: >> >> > Does a write lock:
>> >> > 1. Just the columns in question for the specific row= in question ?
>> >> > 2. The full row in question ?
>> >> > 3. The full CF ?
>> >> >
>> >> > I doubt read does any locks.
>> >> >
>> >> > Thanks.
>> >>
>> >
>> >
>> >
>> > --
>> > It's always darkest just before you are eaten by a grue.<= br> >
>
>
> --
> It's always darkest just before you are eaten by a grue.
>



--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.c= om



--
It's always darkest just before you are eaten by a grue.



--
It'= ;s always darkest just before you are eaten by a grue.






--
It's always darkest= just before you are eaten by a grue.
--bcaec543076ed42eba04a78f91f7--