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 mailto
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
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 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,
> the
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 Netf
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 pre
