incubator-cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <bl...@orcaware.com>
Subject Re: CAS and long lived locks
Date Tue, 25 Jun 2013 02:37:43 GMT
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>
>
>


Mime
View raw message