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 >
