You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Blair Zajac <bl...@orcaware.com> on 2013/06/22 21:09:48 UTC
CAS and long lived locks
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
[2] http://media.fightmymonster.com/Shared/docs/Wait%20Chain%20Algorithm.pdf
Re: CAS and long lived locks
Posted by Blair Zajac <bl...@orcaware.com>.
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 <kohlisankalp@gmail.com
> <ma...@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 <blair@orcaware.com
> <ma...@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>
>
>
>
Re: CAS and long lived locks
Posted by sankalp kohli <ko...@gmail.com>.
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 <ko...@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>
>>
>
>
Re: CAS and long lived locks
Posted by Blair Zajac <bl...@orcaware.com>.
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"
locks.
Blair
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 <blair@orcaware.com
> <ma...@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>
>
>
Re: CAS and long lived locks
Posted by sankalp kohli <ko...@gmail.com>.
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>
>