If you look at https://github.com/Netflix/astyanax/wiki , they have both distributed lock, as well as a uniqueness constraint recipe.
Once you get past the thrift/astyanax style code, the underlying principle is fairly simple which you should be able to port it to CQL3. Thanks, Daniel On Tue, Feb 25, 2014 at 1:26 PM, John Stager <john.sta...@gmail.com> wrote: > > 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.sta...@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.sta...@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 >
