Actually, the data will be visible at QUORUM as well if you can see it
with ONE. QUORUM actually gives you a higher chance of seeing the new
value than ONE does. In the case of R=3 you have 2/3 chance of seeing
the new value with QUORUM, with ONE you have 1/3... And this JIRA fixed
an issue where two QUORUM reads in a row could give you the NEW value
and then the OLD value.
https://issues.apache.org/jira/browse/CASSANDRA-2494
So quorum read on fail for a single row always gives consistent results
now. For multiple rows your still have issues, but you can always
mitigate that in app with something like giving all of the changes the
same time stamp, and then on read checking to make sure the time stamps
match, and reading the data again if they don't.
I'm not arguing against atomic batch operations, they would be nice =).
Just clarifying how things work now.
-Jeremiah
On 11/06/2011 02:05 PM, Pierre Chalamet wrote:
- support for atomic operations or batches (if QUORUM fails, data should
not be visible with ONE)
zookeeper is solving that.
I might have screwed up a little bit since I didn't talk about isolation;
let's reformulate: support for read committed (using DB terminology).
Cassandra is more like read uncommitted.
Even if row mutations in one CF for one key are atomic on one server , stuff
is not rolled back when the CL can't be satisfied at the coordinator level.
Data won't be visible at QUORUM level, but when using weaker CL, invalid
data can appear imho.
Also it should be possible to tell which operations failed with batch_mutate
but unfortunately it is not
