Also CAS is in 2.0 which is not production ready so I am not sure how you will use it.
On Mon, Jun 24, 2013 at 4:35 PM, sankalp kohli <kohlisank...@gmail.com>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 <bl...@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> >> > >
