ok great, thanks ed, that's really helpful.
just wanted to make sure i wasn't missing something fundamental.
On 13/11/2011 23:57, Ed Anuff wrote:
Yes, correct, it's not going to clean itself. Using your example with
a little more detail:
1 ) A(T1) reads previous location (T0,L0) from index_en
Yes, correct, it's not going to clean itself. Using your example with
a little more detail:
1 ) A(T1) reads previous location (T0,L0) from index_entries for user U0
2 ) B(T2) reads previous location (T0,L0) from index_entries for user U0
3 ) A(T1) deletes previous location (T0,L0) from index_entr
[1] i'm not particularly worried about transient conditions so that's
ok. i think there's still the possibility of a non-transient false
positive...if 2 writes were to happen at exactly the same time (highly
unlikely), eg
1) A reads previous location (L1) from index entries
2) B reads previou
1) The index updates should be eventually consistent. This does mean
that you can get a transient false-positive on your search results.
If this doesn't work for you, then you either need to use ZK or some
other locking solution or do "read repair" by making sure that the row
you retrieve contains
help?
On 10/11/2011 19:34, Guy Incognito wrote:
hi,
i've been looking at the model below from Ed Anuff's presentation at
Cassandra CF
(http://www.slideshare.net/edanuff/indexing-in-cassandra). Couple of
questions:
1) Isn't there still the chance that two concurrent updates may end up
wit
hi,
i've been looking at the model below from Ed Anuff's presentation at
Cassandra CF (http://www.slideshare.net/edanuff/indexing-in-cassandra).
Couple of questions:
1) Isn't there still the chance that two concurrent updates may end up
with the index containing two entries for the given us
