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 <ober...@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-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 <jef...@gmail.com>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 <jef...@gmail.com>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 <jbel...@gmail.com>wrote: >>> >>>> Sounds to me like you're confusing atomicity with isolation. >>>> >>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <jef...@gmail.com> >>>> 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 <teddyyyy...@gmail.com> wrote: >>>> >> >>>> >> no , the memtable is a concurrentskiplistmap >>>> >> >>>> >> insertion can happen in parallel >>>> >> >>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <jef...@gmail.com> >>>> 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 <teddyyyy...@gmail.com> >>>> 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" <s5a...@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. >>>> > >>>> > >>>> > >>>> > -- >>>> > 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.
