You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by A J <s5...@gmail.com> on 2011/07/07 19:51:17 UTC
What does a write lock ?
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.
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
Yup, im even more confused. Lets tlak about the model, not the
implementation.
AIUI updates to a single 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
underneath the validation call?
On Thu, Jul 7, 2011 at 3:43 PM, Yang <te...@gmail.com> wrote:
> no , the memtable is a concurrentskiplistmap
>
> insertion can happen in parallel
> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by William Oberman <ob...@civicscience.com>.
Disregard most of my post (already). I forgot that reads aren't isolated.
That means A and B are states cassandra will *eventually* be in, but at any
point in time a read might see a "partial B" (where some columns are still
A, and others are B). Though, I'm sure someone else will confirm if I'm
wrong yet again.
For me, if I need two pieces of data to be consistently related to each
other and stored in cassandra, I encode them (usually JSON) and store them
in one column.
will
On Fri, Jul 8, 2011 at 8:30 AM, William Oberman <ob...@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 <je...@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 <je...@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 <jb...@gmail.com>wrote:
>>>
>>>> Sounds to me like you're confusing atomicity with isolation.
>>>>
>>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>>>> >>
>>>> >> no , the memtable is a concurrentskiplistmap
>>>> >>
>>>> >> insertion can happen in parallel
>>>> >>
>>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
>>
>
>
>
>
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
Where does a custom validation method run?
Given that it is validating a row update, my assumption was that it ran on
the node that "owns" the row. That would make sense to me as it would
fulfill the NoSql philosophy of taking computation to data, rather then data
to computation.
I don't follow the relevance of the rest of your comment, sorry.
On Fri, Jul 8, 2011 at 10:34 AM, Jonathan Ellis <jb...@gmail.com> wrote:
> It doesn't look like that at all.
>
> Row A exists.
>
> Client submits mutation Am. This is not necessarily a full row.
>
> Coordinator validates Am.
>
> If validation succeeds, coordinator sends Am to the replica owners,
> effectively creating A'.
>
> Neither A nor A' is ever explicitly assembled on the write path.
>
> On Fri, Jul 8, 2011 at 9:22 AM, Jeffrey Kesselman <je...@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 <
> 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-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 <je...@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 <je...@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 <jb...@gmail.com>
> >>>> wrote:
> >>>>>
> >>>>> Sounds to me like you're confusing atomicity with isolation.
> >>>>>
> >>>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com>
> wrote:
> >>>>> >>
> >>>>> >> no , the memtable is a concurrentskiplistmap
> >>>>> >>
> >>>>> >> insertion can happen in parallel
> >>>>> >>
> >>>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
> >
>
>
>
> --
> 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.
Re: What does a write lock ?
Posted by Jonathan Ellis <jb...@gmail.com>.
It doesn't look like that at all.
Row A exists.
Client submits mutation Am. This is not necessarily a full row.
Coordinator validates Am.
If validation succeeds, coordinator sends Am to the replica owners,
effectively creating A'.
Neither A nor A' is ever explicitly assembled on the write path.
On Fri, Jul 8, 2011 at 9:22 AM, Jeffrey Kesselman <je...@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 <ob...@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 <je...@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 <je...@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 <jb...@gmail.com>
>>>> wrote:
>>>>>
>>>>> Sounds to me like you're confusing atomicity with isolation.
>>>>>
>>>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>>>>> >>
>>>>> >> no , the memtable is a concurrentskiplistmap
>>>>> >>
>>>>> >> insertion can happen in parallel
>>>>> >>
>>>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com
Re: What does a write lock ?
Posted by William Oberman <ob...@civicscience.com>.
Also, one point of early confusion for me is there is a slightly different
definition of "atomicity" depending on if your talking software vs.
database, and I'm a "software guy". From wikipedia:
Software = Atomicity is a guarantee of isolation from concurrent processes.
Additionally, atomic operations commonly have a succeed-or-fail definition —
they either successfully change the state of the system, or have no visible
effect.
Database = In an atomic transaction, a series of database operations either
all occur, or nothing occurs.
I believe that cassandra is using the database definition.
will
On Fri, Jul 8, 2011 at 10:35 AM, William Oberman
<ob...@civicscience.com>wrote:
> 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 <je...@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 <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-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 <je...@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 <je...@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 <jb...@gmail.com>wrote:
>>>>>
>>>>>> Sounds to me like you're confusing atomicity with isolation.
>>>>>>
>>>>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>>>>>> >>
>>>>>> >> no , the memtable is a concurrentskiplistmap
>>>>>> >>
>>>>>> >> insertion can happen in parallel
>>>>>> >>
>>>>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
>>
>
>
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
I should add, Nate, that the intention is to do a read before write
validation and have that occur as close to the data as possible.
if there is a better hook to implement it on I'd love a pointer to it.
JK
On Fri, Jul 8, 2011 at 12:21 PM, Nate McCall <na...@datastax.com> wrote:
> Validation occurs at the API level, returning an
> InvalidRequestException to the caller of the API (a thrift client in
> this case). Specifically, a mutation will not be scheduled for the
> storage until it has been validated at the API level.
>
> If the intention is to do a read-before-write validation as an
> AbstractType extension, then yes, the underlying value could indeed
> change between validation and storage. If this were the goal, you need
> to implement locking externally (via zookeper or similar as previously
> mentioned).
>
> On Fri, Jul 8, 2011 at 10:21 AM, William Oberman
> <ob...@civicscience.com> wrote:
> > I haven't ever written my own
> org.apache.cassandra.db.marshal.AbstractType
> > (which is I think what your talking about), so I have no idea.
> >
> > Looking up the JavaDoc for that class, validate says "validate that the
> byte
> > array is a valid sequence for the type we are supposed to be comparing",
> > which sounds like a local operation to me (e.g. it shouldn't fetch remote
> > data, it's just saying "yep, this is a valid member of type T").
> >
> > will
> >
> > On Fri, Jul 8, 2011 at 11:17 AM, Jeffrey Kesselman <je...@gmail.com>
> wrote:
> >>
> >> Alright,
> >> So are you saying the column validator, as specified
> >> by conf/storage-conf.xml is checked in the client interface library and
> not
> >> on the server side? That seems odd to me on a number of levels, not the
> >> least being I cant see how thrift could autogenerate that
> >> for different languages or how those other languages would use a Java
> class.
> >>
> >> On Fri, Jul 8, 2011 at 11:13 AM, William Oberman
> >> <ob...@civicscience.com> wrote:
> >>>
> >>> I use a language specific wrapper around thrift as my "client", but
> yes,
> >>> I guess I fundamentally mean thrift == client, and the cassandra server
> ==
> >>> server.
> >>>
> >>> will
> >>>
> >>> On Fri, Jul 8, 2011 at 11:08 AM, Jeffrey Kesselman <je...@gmail.com>
> >>> wrote:
> >>>>
> >>>> I am confused by what you mean by "Cassandra client code." Is this
> part
> >>>> of the Cassnadra server?
> >>>> My architecture is my "user" talks thrift to Cassandra.
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> It's always darkest just before you are eaten by a grue.
> >
> >
> >
>
--
It's always darkest just before you are eaten by a grue.
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
Hmm.
Thanks Nate.
I need to think about this and our data store design some. In general I
dislike architecture with large numbers of independent servers, I think it
invites communication latencies and partial failures into the mix. But I'll
cogitate some.
On Fri, Jul 8, 2011 at 12:21 PM, Nate McCall <na...@datastax.com> wrote:
> Validation occurs at the API level, returning an
> InvalidRequestException to the caller of the API (a thrift client in
> this case). Specifically, a mutation will not be scheduled for the
> storage until it has been validated at the API level.
>
> If the intention is to do a read-before-write validation as an
> AbstractType extension, then yes, the underlying value could indeed
> change between validation and storage. If this were the goal, you need
> to implement locking externally (via zookeper or similar as previously
> mentioned).
>
> On Fri, Jul 8, 2011 at 10:21 AM, William Oberman
> <ob...@civicscience.com> wrote:
> > I haven't ever written my own
> org.apache.cassandra.db.marshal.AbstractType
> > (which is I think what your talking about), so I have no idea.
> >
> > Looking up the JavaDoc for that class, validate says "validate that the
> byte
> > array is a valid sequence for the type we are supposed to be comparing",
> > which sounds like a local operation to me (e.g. it shouldn't fetch remote
> > data, it's just saying "yep, this is a valid member of type T").
> >
> > will
> >
> > On Fri, Jul 8, 2011 at 11:17 AM, Jeffrey Kesselman <je...@gmail.com>
> wrote:
> >>
> >> Alright,
> >> So are you saying the column validator, as specified
> >> by conf/storage-conf.xml is checked in the client interface library and
> not
> >> on the server side? That seems odd to me on a number of levels, not the
> >> least being I cant see how thrift could autogenerate that
> >> for different languages or how those other languages would use a Java
> class.
> >>
> >> On Fri, Jul 8, 2011 at 11:13 AM, William Oberman
> >> <ob...@civicscience.com> wrote:
> >>>
> >>> I use a language specific wrapper around thrift as my "client", but
> yes,
> >>> I guess I fundamentally mean thrift == client, and the cassandra server
> ==
> >>> server.
> >>>
> >>> will
> >>>
> >>> On Fri, Jul 8, 2011 at 11:08 AM, Jeffrey Kesselman <je...@gmail.com>
> >>> wrote:
> >>>>
> >>>> I am confused by what you mean by "Cassandra client code." Is this
> part
> >>>> of the Cassnadra server?
> >>>> My architecture is my "user" talks thrift to Cassandra.
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> It's always darkest just before you are eaten by a grue.
> >
> >
> >
>
--
It's always darkest just before you are eaten by a grue.
Re: What does a write lock ?
Posted by Nate McCall <na...@datastax.com>.
Validation occurs at the API level, returning an
InvalidRequestException to the caller of the API (a thrift client in
this case). Specifically, a mutation will not be scheduled for the
storage until it has been validated at the API level.
If the intention is to do a read-before-write validation as an
AbstractType extension, then yes, the underlying value could indeed
change between validation and storage. If this were the goal, you need
to implement locking externally (via zookeper or similar as previously
mentioned).
On Fri, Jul 8, 2011 at 10:21 AM, William Oberman
<ob...@civicscience.com> wrote:
> I haven't ever written my own org.apache.cassandra.db.marshal.AbstractType
> (which is I think what your talking about), so I have no idea.
>
> Looking up the JavaDoc for that class, validate says "validate that the byte
> array is a valid sequence for the type we are supposed to be comparing",
> which sounds like a local operation to me (e.g. it shouldn't fetch remote
> data, it's just saying "yep, this is a valid member of type T").
>
> will
>
> On Fri, Jul 8, 2011 at 11:17 AM, Jeffrey Kesselman <je...@gmail.com> wrote:
>>
>> Alright,
>> So are you saying the column validator, as specified
>> by conf/storage-conf.xml is checked in the client interface library and not
>> on the server side? That seems odd to me on a number of levels, not the
>> least being I cant see how thrift could autogenerate that
>> for different languages or how those other languages would use a Java class.
>>
>> On Fri, Jul 8, 2011 at 11:13 AM, William Oberman
>> <ob...@civicscience.com> wrote:
>>>
>>> I use a language specific wrapper around thrift as my "client", but yes,
>>> I guess I fundamentally mean thrift == client, and the cassandra server ==
>>> server.
>>>
>>> will
>>>
>>> On Fri, Jul 8, 2011 at 11:08 AM, Jeffrey Kesselman <je...@gmail.com>
>>> wrote:
>>>>
>>>> I am confused by what you mean by "Cassandra client code." Is this part
>>>> of the Cassnadra server?
>>>> My architecture is my "user" talks thrift to Cassandra.
>>>>
>>>
>>
>>
>>
>> --
>> It's always darkest just before you are eaten by a grue.
>
>
>
Re: What does a write lock ?
Posted by William Oberman <ob...@civicscience.com>.
I haven't ever written my own org.apache.cassandra.db.marshal.AbstractType
(which is I think what your talking about), so I have no idea.
Looking up the JavaDoc for that class, validate says "validate that the byte
array is a valid sequence for the type we are supposed to be comparing",
which sounds like a local operation to me (e.g. it shouldn't fetch remote
data, it's just saying "yep, this is a valid member of type T").
will
On Fri, Jul 8, 2011 at 11:17 AM, Jeffrey Kesselman <je...@gmail.com> wrote:
> Alright,
>
> So are you saying the column validator, as specified
> by conf/storage-conf.xml is checked in the client interface library and not
> on the server side? That seems odd to me on a number of levels, not the
> least being I cant see how thrift could autogenerate that
> for different languages or how those other languages would use a Java class.
> *
> *
> On Fri, Jul 8, 2011 at 11:13 AM, William Oberman <oberman@civicscience.com
> > wrote:
>
>> I use a language specific wrapper around thrift as my "client", but yes, I
>> guess I fundamentally mean thrift == client, and the cassandra server ==
>> server.
>>
>> will
>>
>>
>> On Fri, Jul 8, 2011 at 11:08 AM, Jeffrey Kesselman <je...@gmail.com>wrote:
>>
>>> I am confused by what you mean by "Cassandra client code." Is this part
>>> of the Cassnadra server?
>>>
>>> My architecture is my "user" talks thrift to Cassandra.
>>>
>>>
>>>
>>
>
>
> --
> It's always darkest just before you are eaten by a grue.
>
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
Alright,
So are you saying the column validator, as specified
by conf/storage-conf.xml is checked in the client interface library and not
on the server side? That seems odd to me on a number of levels, not the
least being I cant see how thrift could autogenerate that
for different languages or how those other languages would use a Java class.
*
*
On Fri, Jul 8, 2011 at 11:13 AM, William Oberman
<ob...@civicscience.com>wrote:
> I use a language specific wrapper around thrift as my "client", but yes, I
> guess I fundamentally mean thrift == client, and the cassandra server ==
> server.
>
> will
>
>
> On Fri, Jul 8, 2011 at 11:08 AM, Jeffrey Kesselman <je...@gmail.com>wrote:
>
>> I am confused by what you mean by "Cassandra client code." Is this part
>> of the Cassnadra server?
>>
>> My architecture is my "user" talks thrift to Cassandra.
>>
>>
>>
>
--
It's always darkest just before you are eaten by a grue.
Re: What does a write lock ?
Posted by William Oberman <ob...@civicscience.com>.
I use a language specific wrapper around thrift as my "client", but yes, I
guess I fundamentally mean thrift == client, and the cassandra server ==
server.
will
On Fri, Jul 8, 2011 at 11:08 AM, Jeffrey Kesselman <je...@gmail.com> wrote:
> I am confused by what you mean by "Cassandra client code." Is this part of
> the Cassnadra server?
>
> My architecture is my "user" talks thrift to Cassandra.
>
>
>
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
I am confused by what you mean by "Cassandra client code." Is this part of
the Cassnadra server?
My architecture is my "user" talks thrift to Cassandra.
Re: What does a write lock ?
Posted by William Oberman <ob...@civicscience.com>.
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 <je...@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 <ob...@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 <je...@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 <je...@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 <jb...@gmail.com>wrote:
>>>>
>>>>> Sounds to me like you're confusing atomicity with isolation.
>>>>>
>>>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>>>>> >>
>>>>> >> no , the memtable is a concurrentskiplistmap
>>>>> >>
>>>>> >> insertion can happen in parallel
>>>>> >>
>>>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
>
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
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 <ob...@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 <je...@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 <je...@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 <jb...@gmail.com>wrote:
>>>
>>>> Sounds to me like you're confusing atomicity with isolation.
>>>>
>>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>>>> >>
>>>> >> no , the memtable is a concurrentskiplistmap
>>>> >>
>>>> >> insertion can happen in parallel
>>>> >>
>>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by William Oberman <ob...@civicscience.com>.
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 <je...@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 <je...@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 <jb...@gmail.com>wrote:
>>
>>> Sounds to me like you're confusing atomicity with isolation.
>>>
>>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>>> >>
>>> >> no , the memtable is a concurrentskiplistmap
>>> >>
>>> >> insertion can happen in parallel
>>> >>
>>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
>
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
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 <je...@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 <jb...@gmail.com> wrote:
>
>> Sounds to me like you're confusing atomicity with isolation.
>>
>> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>> >>
>> >> no , the memtable is a concurrentskiplistmap
>> >>
>> >> insertion can happen in parallel
>> >>
>> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
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 <jb...@gmail.com> wrote:
> Sounds to me like you're confusing atomicity with isolation.
>
> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
> >>
> >> no , the memtable is a concurrentskiplistmap
> >>
> >> insertion can happen in parallel
> >>
> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
Not confusing, but assuming a few things.
I made a more detailed post in the Datatstax forums.
On Thu, Jul 7, 2011 at 10:27 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> Sounds to me like you're confusing atomicity with isolation.
>
> On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
> >>
> >> no , the memtable is a concurrentskiplistmap
> >>
> >> insertion can happen in parallel
> >>
> >> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by Jonathan Ellis <jb...@gmail.com>.
Sounds to me like you're confusing atomicity with isolation.
On Thu, Jul 7, 2011 at 2:54 PM, Jeffrey Kesselman <je...@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 <te...@gmail.com> wrote:
>>
>> no , the memtable is a concurrentskiplistmap
>>
>> insertion can happen in parallel
>>
>> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
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 <te...@gmail.com> wrote:
> no , the memtable is a concurrentskiplistmap
>
> insertion can happen in parallel
> On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by Yang <te...@gmail.com>.
no , the memtable is a concurrentskiplistmap
insertion can happen in parallel
On Jul 7, 2011 9:24 AM, "Jeffrey Kesselman" <je...@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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
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 <te...@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" <s5...@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.
Re: What does a write lock ?
Posted by Yang <te...@gmail.com>.
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" <s5...@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.
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
The old row is accessible and my validation requires a comparison of the
two.
JK
On Thu, Jul 7, 2011 at 3:23 PM, Yang <te...@gmail.com> wrote:
> validation is on the new incoming column ,not the old row,right?
> On Jul 7, 2011 8:25 AM, "Jeffrey Kesselman" <je...@gmail.com> wrote:
> > Hi Jonnathan,
> >
> > This brings up an important question. I have been assuming that the
> > validation check is part of the atomic update operation. Is this NOT the
> > case? Which is to say, can the row be changed between the time the
> > validation method is executed and the validated data is written?
> >
> > The reason I ask is because I have been thinking of this as effectively a
> > write-lock on the row during the entire update
> > process, including validation, but your answer has caused some concerns
> that
> > this is wrong...
> >
> > Thanks
> >
> > JK
> >
> > On Thu, Jul 7, 2011 at 2:01 PM, Jonathan Ellis <jb...@gmail.com>
> wrote:
> >
> >> None of the above, it uses a glorified CAS* at the column level
> >>
> >> *http://en.wikipedia.org/wiki/Compare-and-swap
> >>
> >> On Thu, Jul 7, 2011 at 12:51 PM, A J <s5...@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.
> >> >
> >>
> >>
> >>
> >> --
> >> 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.
Re: What does a write lock ?
Posted by Yang <te...@gmail.com>.
validation is on the new incoming column ,not the old row,right?
On Jul 7, 2011 8:25 AM, "Jeffrey Kesselman" <je...@gmail.com> wrote:
> Hi Jonnathan,
>
> This brings up an important question. I have been assuming that the
> validation check is part of the atomic update operation. Is this NOT the
> case? Which is to say, can the row be changed between the time the
> validation method is executed and the validated data is written?
>
> The reason I ask is because I have been thinking of this as effectively a
> write-lock on the row during the entire update
> process, including validation, but your answer has caused some concerns
that
> this is wrong...
>
> Thanks
>
> JK
>
> On Thu, Jul 7, 2011 at 2:01 PM, Jonathan Ellis <jb...@gmail.com> wrote:
>
>> None of the above, it uses a glorified CAS* at the column level
>>
>> *http://en.wikipedia.org/wiki/Compare-and-swap
>>
>> On Thu, Jul 7, 2011 at 12:51 PM, A J <s5...@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.
>> >
>>
>>
>>
>> --
>> 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.
Re: What does a write lock ?
Posted by Jeffrey Kesselman <je...@gmail.com>.
Hi Jonnathan,
This brings up an important question. I have been assuming that the
validation check is part of the atomic update operation. Is this NOT the
case? Which is to say, can the row be changed between the time the
validation method is executed and the validated data is written?
The reason I ask is because I have been thinking of this as effectively a
write-lock on the row during the entire update
process, including validation, but your answer has caused some concerns that
this is wrong...
Thanks
JK
On Thu, Jul 7, 2011 at 2:01 PM, Jonathan Ellis <jb...@gmail.com> wrote:
> None of the above, it uses a glorified CAS* at the column level
>
> *http://en.wikipedia.org/wiki/Compare-and-swap
>
> On Thu, Jul 7, 2011 at 12:51 PM, A J <s5...@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.
> >
>
>
>
> --
> 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.
Re: What does a write lock ?
Posted by Jonathan Ellis <jb...@gmail.com>.
None of the above, it uses a glorified CAS* at the column level
*http://en.wikipedia.org/wiki/Compare-and-swap
On Thu, Jul 7, 2011 at 12:51 PM, A J <s5...@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.
>
--
Jonathan Ellis
Project Chair, Apache Cassandra
co-founder of DataStax, the source for professional Cassandra support
http://www.datastax.com