Return-Path: X-Original-To: apmail-cassandra-user-archive@www.apache.org Delivered-To: apmail-cassandra-user-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 2767E10484 for ; Tue, 25 Feb 2014 22:00:12 +0000 (UTC) Received: (qmail 80632 invoked by uid 500); 25 Feb 2014 22:00:07 -0000 Delivered-To: apmail-cassandra-user-archive@cassandra.apache.org Received: (qmail 80609 invoked by uid 500); 25 Feb 2014 22:00:07 -0000 Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cassandra.apache.org Delivered-To: mailing list user@cassandra.apache.org Received: (qmail 80596 invoked by uid 99); 25 Feb 2014 22:00:06 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Feb 2014 22:00:06 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of danchia@coursera.org designates 209.85.216.176 as permitted sender) Received: from [209.85.216.176] (HELO mail-qc0-f176.google.com) (209.85.216.176) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Feb 2014 22:00:02 +0000 Received: by mail-qc0-f176.google.com with SMTP id r5so48747qcx.35 for ; Tue, 25 Feb 2014 13:59:40 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:content-type; bh=10AnnSEFxT5eEkwK7Yrhck2/M8h41ynuvRW1oPWbJqI=; b=a18YgCo24hsA5dyUK7UyOKGFBe3dK9TafeKyWVzmN9vb7pposxL53G4JzmpXTVfFl1 3XiWTvq5hazT7dhXAndJapbd1hPp9CRXIuR8RYdqAUmq9lVf8fCGetPw+VuGVmxdpi6y WW5luRONHus0gQpawMwxHgW6foHJm6lVxXyk7pSvtgd/CFkqyWbYMhbosuo35w/dntx3 4iNOu8LYIHp3DIuG4kH33iozWQZRpg75HgyAWtRfltigGhPnEEXeViTtLlg9DAOU51sL FCpmmrA5uHqHIum5PZgXNSfGtFhFWkZ2CKYVUjqRLbiaeGd9REEAnT50vrwegPxvP/Z/ 8tuQ== X-Gm-Message-State: ALoCoQmUmfiLD0Sr0jGrMO72RvqxrYIch4UOjbLvoQ/r/fKha7ogad/u1iBmb97AILo1lf+p4+5x X-Received: by 10.224.137.66 with SMTP id v2mr3411335qat.104.1393365580701; Tue, 25 Feb 2014 13:59:40 -0800 (PST) MIME-Version: 1.0 Received: by 10.229.116.197 with HTTP; Tue, 25 Feb 2014 13:59:19 -0800 (PST) In-Reply-To: References: <530C0B1A.8000705@pbandjelly.org> <20140225032441.6348948.2630.1266@gmail.com> <530C20F4.2010601@pbandjelly.org> <20140225134126.6348948.59407.1288@gmail.com> <20140225192407.6348948.83106.1308@gmail.com> <20140225192535.6348948.43324.1311@gmail.com> From: Daniel Chia Date: Tue, 25 Feb 2014 13:59:19 -0800 Message-ID: Subject: Re: Cassandra Data Model and Surrogate Keys To: user@cassandra.apache.org Content-Type: multipart/alternative; boundary=001a11c2ccd47b19a904f3423485 X-Virus-Checked: Checked by ClamAV on apache.org --001a11c2ccd47b19a904f3423485 Content-Type: text/plain; charset=ISO-8859-1 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 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, 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 > --001a11c2ccd47b19a904f3423485 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
If you look at=A0https://github.com/Netflix/astyanax/wiki , they have both d= istributed lock, as well as a uniqueness constraint recipe.

<= div> 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 St= ager <john.stager@gmail.com> wrote:

Hello Daniel,

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

We are using cql= 3 with the Datastax java driver

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

Hi John,

Since this is p= resumably for creation of users, which should have low activity per user, y= ou 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 work= s for C1.2 (although you might have to port it to CQL3 if that's what y= ou're using).

Thanks,
Daniel<= /div>


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 hav= e 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.
=A0 Original Message =A0
From: Michael Shuler
Sent: Monday, February 24, 2014 11:53 PM
To: use= r@cassandra.apache.org
Reply To: us= er@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,<= br> > sorry). Are there any recommendations for 1.2, or do you just have to<= br> > 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<= br> around with locking. Someone may correct me, if there are better
alternatives. I simple example attached.

Michael






--
John W Stager

--001a11c2ccd47b19a904f3423485--