Mixing CAS UPDATE and non-CAS DELETE

[Blair Zajac <bl...@orcaware.com>]

Looking at the CAS unit tests [1], if one does a CAS UPDATE to create a ROW:

   UPDATE test SET v1 = 2, v2 = 'foo' WHERE k = 0 IF NOT EXISTS

there isn't a CAS DELETE FROM that only uses the partition key.  You can 
do this to delete the row using CAS:

   DELETE FROM test WHERE k = 0 IF v1 = null

But if I want to delete it regardless of v1, then this doesn't work:

   DELETE FROM test WHERE k = 0 IF EXISTS

So one is left to

   DELETE FROM test WHERE k = 0

How does this non-CAS DELETE mix with a CAS UPDATE for the same 
partition key?  Will they properly not step over each other?

Thanks,
Blair

[1] 
https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044

Re: Mixing CAS UPDATE and non-CAS DELETE

[Blair Zajac <bl...@orcaware.com>]

On 6/26/13 10:26 AM, Sylvain Lebresne wrote:
> On Tue, Jun 25, 2013 at 5:30 AM, Blair Zajac <blair@orcaware.com
> <ma...@orcaware.com>> wrote:
>
>     But if I want to delete it regardless of v1, then this doesn't work:
>
>        DELETE FROM test WHERE k = 0 IF EXISTS
>
>
> That's correct, though we should probably fix that at some point. I've
> opened https://issues.apache.org/jira/browse/CASSANDRA-5708 for that.

I was thinking about this and wondering if there's even a point to 
having a CAS delete in this case?  Is "DELETE FROM test WHERE k = 0" the 
same as "DELETE FROM test WHERE k = 0 IF EXISTS" from a practical point 
of view?  One is still racing with any other updates to the row, either 
with  the proposal from other CASes or an implicit race with whoever has 
a later timestamp?

Does one save a row tombstone if one uses "IF EXISTS"?

>     So one is left to
>
>        DELETE FROM test WHERE k = 0
>
>     How does this non-CAS DELETE mix with a CAS UPDATE for the same
>     partition key?  Will they properly not step over each other?
>
>
> Depends on what you mean by "not step over each other". A CAS update
> will end up inserting columns with a timestamp that is basically the one
> of the start of the paxos algorithm use underneath. The delete itself
> will be a tombstone with a timestamp of when you execute that delete. So
> the basic rule of "the more recent wins" will apply. Of course if 2 such
> operations contend, you can't really know which will win. But if you do
> a delete at QUORUM, followed by a CAS update IF NOT EXISTS (and there is
> no other concurrently running operation on that row) you are guaranteed
> that your update will succeed.
>
> I don't know if I've answered your question.

Yes, thanks.  I was wondering if the non-CAS delete ignores any 
outstanding proposals on the row.

Blair

Re: Mixing CAS UPDATE and non-CAS DELETE

[Sylvain Lebresne <sy...@datastax.com>]

On Tue, Jun 25, 2013 at 5:30 AM, Blair Zajac <bl...@orcaware.com> wrote:

> But if I want to delete it regardless of v1, then this doesn't work:
>
>   DELETE FROM test WHERE k = 0 IF EXISTS
>

That's correct, though we should probably fix that at some point. I've
opened https://issues.apache.org/jira/browse/CASSANDRA-5708 for that.


> So one is left to
>
>   DELETE FROM test WHERE k = 0
>
> How does this non-CAS DELETE mix with a CAS UPDATE for the same partition
> key?  Will they properly not step over each other?
>

Depends on what you mean by "not step over each other". A CAS update will
end up inserting columns with a timestamp that is basically the one of the
start of the paxos algorithm use underneath. The delete itself will be a
tombstone with a timestamp of when you execute that delete. So the basic
rule of "the more recent wins" will apply. Of course if 2 such operations
contend, you can't really know which will win. But if you do a delete at
QUORUM, followed by a CAS update IF NOT EXISTS (and there is no other
concurrently running operation on that row) you are guaranteed that your
update will succeed.

I don't know if I've answered your question.

--
Sylvain



>
> Thanks,
> Blair
>
> [1] https://github.com/riptano/**cassandra-dtest/blob/master/**
> cql_tests.py#L3044<https://github.com/riptano/cassandra-dtest/blob/master/cql_tests.py#L3044>
>