I think you need to look into Zookeeper, or other distributed coordinator, as you have little/no guarantees from cassandra between 1-3 (in terms of the guarantees you want and need).
And my terminology in my post is different than yours. My "client" == your "server". Specifically, I was thinking in terms of: user -> cassandra client code (that runs on a "server") -> cassandra server code (e.g. cassandra itself) that runs either on the same or different server On Fri, Jul 8, 2011 at 10:22 AM, Jeffrey Kesselman <jef...@gmail.com> wrote: > 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. >
