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 frewstore@gmail.com designates
 209.85.211.203 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=mime-version:sender:in-reply-to:references:date
         :x-google-sender-auth:message-id:subject:from:to:content-type
         :content-transfer-encoding;
        b=QYk3LD2qGpKjvzWwb9cmVuN4jXXAe7fRVwnFsoVBV4dXzs7OhRsXr3ETOAv0sDnyDo
         ngqSQuI7G6U5eZ6Pi2h7WluvzwcOOwWRhOpZkC4cAdit/Jh6krUfNK1KRr/CKxN9aGcr
         Y2UxcbXbIhJGJkpPuZ8Hh4lkJzLCvLdHotVIk=
MIME-Version: 1.0
Sender: frewstore@gmail.com
In-Reply-To: <bad22a01003140946s17bbde2eu642802b1900b4a12@mail.gmail.com>
References: <bad22a01003140946s17bbde2eu642802b1900b4a12@mail.gmail.com>
Date: Sun, 14 Mar 2010 15:29:41 -0700
Message-ID: <2e191f541003141529v6a194f3dif5060420178f6ff2@mail.gmail.com>
Subject: Re: serialized vector clock as global counter?
From: Fred Wulff <frew@stanford.edu>
To: user@cassandra.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Hey Toby,

I'm not an expert on Cassandra's infrastructure, but I believe the
thing the AppEngine datastore has that Cassandra doesn't is a
transaction between the read and write of a sharded counter. That
means that while the read of the various counters may be inconsistent,
the actual update of the shard is always consistent and the read of
that shard is always consistent with the previous write.

-Fred

On Sun, Mar 14, 2010 at 9:46 AM, Toby DiPasquale <toby@cbcg.net> wrote:
> Hi all,
>
> I'm trying to write an application using Cassandra which requires the
> use of a global, monotonically-increasing counter. I've seen the
> previous threads on this subject which basically say that this can't
> be done in Cassandra as is, but I think I've come up with a method
> that might work. I wanted to get the list's feedback on whether or not
> this method is workable:
>
> * Each client maintains its own monotonically-increasing counter as a
> row in Cassandra
> * When a client wants to increment the counter, it will:
> =A0* increment its own counter key using a quorum write
> =A0* read all keys in the CF using a quorum read
> =A0* the sum of the values is then the value of the counter
>
> This method is robust against nodes coming and going (new nodes just
> get a new counter and dead nodes never increase their counter again).
> It also doesn't matter for my application if some possible values for
> the counter are skipped over, as long as every value is greater than
> the last. I believe this scheme to be commensurate to a vector clock,
> no?
>
> My question would be: assuming we're using both quorum reads and
> writes, is it possible that clients A and B could race in the
> following manner:
>
> * A updates its counter
> * B updates its counter
> * A reads the keys to get sum X
> * B reads the keys to get the same sum X
>
> ...thus violating the ever-increasing constraint?
>
> Google App Engine suggests a similar method for doing global counters
> on Datastore: http://code.google.com/appengine/articles/sharding_counters=
.html.
> I'm troubled by their implementation, though, because the reads on the
> list of counters are not transactional and are potentially subject to
> the same race that I've described above.
>
> Any thoughts/ideas?
>
> --
> Toby DiPasquale
>