incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From William Oberman <ober...@civicscience.com>
Subject Re: What does a write lock ?
Date Fri, 08 Jul 2011 14:48:42 GMT
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
<oberman@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 <jeffpk@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 <jeffpk@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 <jeffpk@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 <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.    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 <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>
>>>>>> 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 <teddyyyy123@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" <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.
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > 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.
>>
>
>

Mime
View raw message