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> >
