Return-Path: Delivered-To: apmail-cassandra-dev-archive@www.apache.org Received: (qmail 34340 invoked from network); 21 Jun 2010 18:00:16 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Jun 2010 18:00:16 -0000 Received: (qmail 39644 invoked by uid 500); 21 Jun 2010 18:00:16 -0000 Delivered-To: apmail-cassandra-dev-archive@cassandra.apache.org Received: (qmail 39580 invoked by uid 500); 21 Jun 2010 18:00:15 -0000 Mailing-List: contact dev-help@cassandra.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@cassandra.apache.org Delivered-To: mailing list dev@cassandra.apache.org Received: (qmail 39572 invoked by uid 99); 21 Jun 2010 18:00:14 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 21 Jun 2010 18:00:14 +0000 X-ASF-Spam-Status: No, hits=2.2 required=10.0 tests=AWL,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [206.190.49.31] (HELO web53001.mail.re2.yahoo.com) (206.190.49.31) by apache.org (qpsmtpd/0.29) with SMTP; Mon, 21 Jun 2010 18:00:06 +0000 Received: (qmail 93339 invoked by uid 60001); 21 Jun 2010 17:59:45 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s1024; t=1277143185; bh=j413XdKqoD+qHp7skznh4k4dzq5Mw3bmRBk34FC8frE=; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=BfRe1jvpw8stlDZlTvEbY8y82TZgJVU5tNBEYByPRFJYrWRJvt4Jjs2XgDXv0OCFlXW73WbhWiK/PC2EuOXV5d756Rn9aJWjgSmq+DaDeXaMCpDO8cVO0BNvhdPRi9PBkcwhAz0BqBGeUJBLU0uccq9XYRSRbbTU1lhk3SBZZ/4= DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=yahoo.com; h=Message-ID:X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:In-Reply-To:MIME-Version:Content-Type; b=Dva3HSFy7nzHjA2M6JbG8Q3GVN6HHUB5bP/lHxSWSicOm3MVe/cKnvOTYWyxJwBhNlcr7dVJOB9XnTeLRuVxs9ZYy3Eoe47B0Phm3w7PFv1CRWeGp9yAQTVP94tFpdno5iPpY+gIgFpHT2tIZ0XcDeo6ci0qy0MX6nDLIzgtIZo=; Message-ID: <597118.93299.qm@web53001.mail.re2.yahoo.com> X-YMail-OSG: dyPlnn0VM1lWxm99l4W.C2IRV2jvmlAY1_0l9pN0VgORcB5 A7V63EpOgxgrk1vRSQMSbFeI335UgFAopMTDixF.MaXmrz5KzpAuAQqlNJf1 7YFBGEZoW2LmRaEItOqf.XNOwFJZG5MPDvz76eFUjPz_dBvGAKKCOKYjvxFf sLT3M_PEzSOCeHYgwAUIb0TGfUZttHJhsGff3T6bJnN04P7Htci4IA4vG8NT 9EBuct6KcMyoluF4Ug8o4wk_DC5mb9E2lOVsn2FsyC3NrIyPbyAAFnMlE8Jt KF.SAUnmtUjo18M0UcIblvbLL6CggLK_OdMGx2QUcq3qupecvRB7Oj2w5svA c Received: from [64.71.26.138] by web53001.mail.re2.yahoo.com via HTTP; Mon, 21 Jun 2010 10:59:45 PDT X-Mailer: YahooMailRC/397.8 YahooMailWebService/0.8.104.274457 References: <928936.19493.qm@web53003.mail.re2.yahoo.com> <1516010789-1277071653-cardhu_decombobulator_blackberry.rim.net-503912487-@bda619.bisx.prod.on.blackberry> <703239.75176.qm@web53004.mail.re2.yahoo.com> <28B0FCEF-29DC-4D6C-9571-A9B296216584@malhar.net> Date: Mon, 21 Jun 2010 10:59:45 -0700 (PDT) From: Rishi Bhardwaj Subject: Re: Atomic Compare and Swap To: dev@cassandra.apache.org In-Reply-To: <28B0FCEF-29DC-4D6C-9571-A9B296216584@malhar.net> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="0-2015589024-1277143185=:93299" --0-2015589024-1277143185=:93299 Content-Type: text/plain; charset=us-ascii I am definitely interested in taking this work up. I believe the CAS functionality would help in a lot of different scenarios and could help avoid use of other external services (like zookeeper) to provide similar functionality. I am new at Cassandra development and would really appreciate pointers from the dev. community about how to approach/start on this project. Also how feasible is the approach mentioned below to implement the CAS functionality? It would be great if we could have a discussion on the pros and cons. Thanks, Rishi ________________________________ From: Sriram Srinivasan To: dev@cassandra.apache.org Sent: Sun, June 20, 2010 9:47:37 PM Subject: Re: Atomic Compare and Swap I too am interested in a CAS facility. I like Rishi's proposal. One could simply use a version number as the logical timestamp. If we promote CAS to a consistency level, it would rate higher than a quorum. One pays the price for a more complex write path to obtain the requisite guarantee. On Jun 21, 2010, at 4:03 AM, Rishi Bhardwaj wrote: > > Heres another thought I had, if say the user always wrote with quorum (or to all) nodes then can't we implement CAS (compare and swap) assuming that user employs logical timestamp and Cassandra doesn't allow writes to a column with same or older timestamp. Here's the scenario I am thinking about: > Say we use logical timestamp for a column value and lets assume the current timestamp is t. Now say two clients read this column and generate concurrent CAS (compare and swap) operations on timestamp t and for both the writes the resulting new timestamp would become (t+1). Now if we don't allow writes to a column with same timestamp then only one of these writes would succeed. Of course another assumption is that if a third CAS write with compare on logical timestamp (t - 1) came in, that would be denied as I believe Cassandra doesn't allow "older" writes to win over "newer" writes. Do you think such a thing can be accomplished? --0-2015589024-1277143185=:93299--