cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Stager <>
Subject Fwd: Cassandra Data Model and Surrogate Keys
Date Tue, 25 Feb 2014 21:26:01 GMT
Hello Daniel,

That is correct this is for user creation and collisions should be rare. Is
the astyanax recipe a distributed lock? I do not understand what you mean
by a combination of reads and writes?

We are using cql3 with the Datastax java driver

  *From: *Daniel Chia
*Sent: *Tuesday, February 25, 2014 2:02 PM
*To: *
*Reply To: *
*Subject: *Re: Cassandra Data Model and Surrogate Keys

Hi John,

Since this is presumably for creation of users, which should have low
activity per user, you can use a combination of reads / writes to acquire a
"lock" on the username. I believe astyanax has a recipe with what you want
that works for C1.2 (although you might have to port it to CQL3 if that's
what you're using).


On Tue, Feb 25, 2014 at 5:41 AM, <> wrote:

> Thanks again Michael. Those are the conclusions that I came to as well.
> For us the window is small for possible duplicate users so I think we will
> have to do the read before like you suggested. We will also have to be able
> to handle the case where the duplicate users exist.
> And thanks for the example cql.
> Thanks
> Sent from my BlackBerry 10 smartphone on the Rogers network.
>   Original Message
> From: Michael Shuler
> Sent: Monday, February 24, 2014 11:53 PM
> To:
> Reply To:
> Subject: Re: Cassandra Data Model and Surrogate Keys
> On 02/24/2014 09:24 PM, wrote:
> > Thanks Michael, I will take a look at LWT for the future but
> > unfortunately we are using Cassandra 1.2 ( I should have stated that,
> > sorry). Are there any recommendations for 1.2, or do you just have to
> > deal with him the race condition and possible duplicate data.
> I think you would need to try to perform a best effort read before write
> in your application. I guess it depends on the amount of traffic for the
> table. Even then, there is a small race window in that turnaround time.
> A nasty alternative would be a distributed lock manager, or you could
> upgrade to 2.0, if that's possible, which would be easier than messing
> around with locking. Someone may correct me, if there are better
> alternatives. I simple example attached.
> Michael

John W Stager

View raw message