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. >
