Mailing-List: contact user-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@cassandra.apache.org
Received-SPF: pass (nike.apache.org: domain of blair@orcaware.com designates
 108.0.197.17 as permitted sender)
Message-ID: <51C90277.5090300@orcaware.com>
Date: Mon, 24 Jun 2013 19:37:43 -0700
From: Blair Zajac <blair@orcaware.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64;
 rv:17.0) Gecko/20130510 Thunderbird/17.0.6
MIME-Version: 1.0
To: user@cassandra.apache.org
CC: sankalp kohli <kohlisankalp@gmail.com>
Subject: Re: CAS and long lived locks
References: <51C5F67C.6000303@orcaware.com>
 <CAEPxca06kJcUfz9P33+4nEEe=OJW0-svVeAbzH7xo2J9rE7Rog@mail.gmail.com>
In-Reply-To: 
 <CAEPxca06kJcUfz9P33+4nEEe=OJW0-svVeAbzH7xo2J9rE7Rog@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I normally have migrations run at server startup and depending upon the 
complexity, they could run for a while if they need to do per-row data 
transformations.  I don't get the point regarding collisions, somebody 
is going to be locked out for a while, so getting the lock for a short 
period and renewing it is the same???

I used the Astyanax client for a bit but the locking recipes don't work 
with CQL3 non-compact tables, when I last tried 2 months ago.

The other advantage of using CAS compared with Astyanax's lock is that 
the write/read operations that Astyanax does are all done server side in 
CAS, plus it avoids the issue of the hinted writes that can cause "lost" 
locks.

Blair

On 06/24/2013 01:35 PM, sankalp kohli wrote:
> Assuming that database migration is a one time and rare operation, why
> don't you try to grab a lock for a short time. If you are able to grab
> it, then you can renew it for a longer time. This will make sure that in
> case of collision, all contenders wont be locked out for long time.
> You can use Netflix client recipe for locks.
>
>
> On Sat, Jun 22, 2013 at 3:09 PM, Blair Zajac <blair@orcaware.com
> <mailto:blair@orcaware.com>> wrote:
>
>     Looking at the Cassandra 13 keynote [1], slide 56 regarding hinted
>     writes causing the lock to be taken even though the client thinks
>     the lock attempt failed, which the new CAS support fixes.
>
>     I have some database migrations to run on Cassandra, so I still need
>     a long lived lock somewhere to prevent two or more migrations
>     running concurrently, so CAS doesn't directly solve this problem.
>
>     It sounds like I could have a BOOLEAN column named "lock" but use
>     CAS to update it from false or NULL value to true and this avoids
>     the problem of hinted updates problem.  The finally block would
>     reset it to false or NULL.  This would be a simpler implementation
>     than using the wait chain algorithm.
>
>     Any problems with this?
>
>     Blair
>
>     [1]
>     http://www.slideshare.net/__jbellis/cassandra-summit-2013-__keynote
>     <http://www.slideshare.net/jbellis/cassandra-summit-2013-keynote>
>     [2]
>     http://media.fightmymonster.__com/Shared/docs/Wait%20Chain%__20Algorithm.pdf
>     <http://media.fightmymonster.com/Shared/docs/Wait%20Chain%20Algorithm.pdf>
>
>