cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <>
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" 


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 <
> <>> 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]
>     <>
>     [2]
>     http://media.fightmymonster.__com/Shared/docs/Wait%20Chain%__20Algorithm.pdf
>     <>

View raw message