Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of JEREMIAH.JORDAN@morningstar.com
 designates 216.228.224.32 as permitted sender)
Message-ID: <4EB80254.7090700@morningstar.com>
Date: Mon, 07 Nov 2011 10:07:48 -0600
From: Jeremiah Jordan <jeremiah.jordan@morningstar.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:7.0.1) Gecko/20110929 Thunderbird/7.0.1
MIME-Version: 1.0
To: user@cassandra.apache.org
Subject: Re: Second Cassandra users survey
References: 
 <CALdd-zjvWsd4r7fS8xL0D2JDzP9Vok2+w7u_4wCyPkfGMxKbPg@mail.gmail.com>
 <001801cc9c02$50625130$f126f390$@chalamet.net> <4EB64AB6.9090307@sendmail.cz>
 <001f01cc9cbf$76f4e7f0$64deb7d0$@chalamet.net>
In-Reply-To: <001f01cc9cbf$76f4e7f0$64deb7d0$@chalamet.net>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

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