incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: Mutations during selects
Date Sat, 10 Sep 2011 02:33:14 GMT
I a thinking about a scenario that goes like this: a node is reading a
secondary index to reply to a select query. While in the middle of this,
two rows are mutated, one that has already been read and considered for
the select result, and one that is yet to be processed. Say both rows
where changed in a way that causes them to be included to the result. The
result however will contain only the second one, and will not represent
the correct select result, neither before or after said mutation.

This is extreme, I know, but given a cluster with enough activity, I don't
believe it's impossible. So I guess the answer is, Cassandra doesn't care,
the result is not guaranteed to represent a valid snapshot of the
database, but is very likely to?


> Consider this scenario in a SQL database:
> UPDATE foo SET x = 1 WHERE key = 'asdf';
> Now, "simultaneously," two clients run
> UPDATE foo SET x = 2 WHERE key = 'asdf';
> and
> SELECT * FROM foo WHERE x = 1;
> Either you get back row asdf, or you don't.  Either is valid.  Same
> thing happens with Cassandra indexes.
> On Fri, Sep 9, 2011 at 10:41 AM,  <> wrote:
>> I see that Cassandra updates secondary indices as soon as a value of the
>> indexed column is updated. This can happen, for example, during a select
>> query with a condition on a secondary index. Does Cassandra perform no
>> checking or locking? Will the result of this select, with old and new
>> values, be returned as is? Am I missing some reason why this isn't a
>> problem?
>> Alexander
> --
> Jonathan Ellis
> Project Chair, Apache Cassandra
> co-founder of DataStax, the source for professional Cassandra support

View raw message