Return-Path: Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: (qmail 26672 invoked from network); 3 Sep 2010 13:13:32 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 3 Sep 2010 13:13:32 -0000 Received: (qmail 38597 invoked by uid 500); 3 Sep 2010 13:13:30 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 38570 invoked by uid 500); 3 Sep 2010 13:13:26 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 38561 invoked by uid 99); 3 Sep 2010 13:13:26 -0000 Received: from Unknown (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Sep 2010 13:13:26 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: local policy) Received: from [85.17.83.17] (HELO mail2.unitedgames.com) (85.17.83.17) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 03 Sep 2010 13:12:56 +0000 Received: from localhost (localhost [127.0.0.1]) by mail2.unitedgames.com (Postfix) with ESMTP id 7FF305EB0A94 for ; Fri, 3 Sep 2010 15:12:36 +0200 (CEST) Received: from mail2.unitedgames.com ([127.0.0.1]) by localhost (mail2.unitedgames.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id RMvjC2KU7vqn for ; Fri, 3 Sep 2010 15:12:36 +0200 (CEST) Received: from [192.168.1.124] (unknown [188.204.191.150]) by mail2.unitedgames.com (Postfix) with ESMTP id EFC575EB0A66 for ; Fri, 3 Sep 2010 15:12:35 +0200 (CEST) Message-ID: <4C80F443.8040106@unitedgames.com> Date: Fri, 03 Sep 2010 15:12:35 +0200 From: Hugo User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2.8) Gecko/20100802 Lightning/1.0b2 Thunderbird/3.1.2 MIME-Version: 1.0 To: user@cassandra.apache.org Subject: Re: Consistency issue References: <4C80D61C.2050302@unitedgames.com> In-Reply-To: Content-Type: multipart/alternative; boundary="------------010000050706090303030601" X-Virus-Checked: Checked by ClamAV on apache.org This is a multi-part message in MIME format. --------------010000050706090303030601 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit I'm using QUORUM, but in my single-node setup this doesn't matter IMHO. On 9/3/2010 1:51 PM, Nick Telford wrote: > Which ConsistencyLevels did you use for your batchMutate() and > getSlice() operations? > > ConsistencyLevels directly dictate the level of consistency you will > get with your data. > > Regards, > > Nick Telford > > On 3 September 2010 12:03, Hugo > wrote: > > Hi, > > I'm performing tests with Cassandra 0.6.5 with Hector 0.6.0-14 on > a single machine (one node cluster). I've noticed an issue with > consistency. > > In my tests I perform a KeySpace.batchMutate() to update a column > and immediately after that I perform a KeySpace.getSlice() on the > same column (from within the same thread). I noticed that > occasionally I get back the previous value rather than the value > I've just written. > > My guess is that this occurs because Hector uses pooled > connections and both my requests are executed on different > connections. I suspect this causes a race condition in Cassandra > between the getSlice() and the batchMutate(). > > Can anyone confirm my suspicions and does anyone have a solution > for this? > > Groets, Hugo. > > --------------010000050706090303030601 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit I'm using QUORUM, but in my single-node setup this doesn't matter IMHO.

On 9/3/2010 1:51 PM, Nick Telford wrote:
Which ConsistencyLevels did you use for your batchMutate() and getSlice() operations?

ConsistencyLevels directly dictate the level of consistency you will get with your data.

Regards,

Nick Telford

On 3 September 2010 12:03, Hugo <hugo@unitedgames.com> wrote:
 Hi,

I'm performing tests with Cassandra 0.6.5 with Hector 0.6.0-14 on a single machine (one node cluster). I've noticed an issue with consistency.

In my tests I perform a KeySpace.batchMutate() to update a column and immediately after that I perform a KeySpace.getSlice() on the same column (from within the same thread). I noticed that occasionally I get back the previous value rather than the value I've just written.

My guess is that this occurs because Hector uses pooled connections and both my requests are executed on different connections. I suspect this causes a race condition in Cassandra between the getSlice() and the batchMutate().

Can anyone confirm my suspicions and does anyone have a solution for this?

Groets, Hugo.

--------------010000050706090303030601--