incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Stager <john.sta...@gmail.com>
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

Thanks
  *From: *Daniel Chia
*Sent: *Tuesday, February 25, 2014 2:02 PM
*To: *user@cassandra.apache.org
*Reply To: *user@cassandra.apache.org
*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).

Thanks,
Daniel


On Tue, Feb 25, 2014 at 5:41 AM, <john.stager@gmail.com> 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: user@cassandra.apache.org
> Reply To: user@cassandra.apache.org
> Subject: Re: Cassandra Data Model and Surrogate Keys
>
> On 02/24/2014 09:24 PM, john.stager@gmail.com 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

Mime
View raw message