Our product is in development now so we don't plan on going into
production later when 2.0.0 is out.
Blair
On 06/24/2013 01:36 PM, sankalp kohli wrote:
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
<mailto: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
<mailto: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>
