cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Blair Zajac <>
Subject Re: Mixing CAS UPDATE and non-CAS DELETE
Date Sat, 29 Jun 2013 19:10:36 GMT
On 6/26/13 10:26 AM, Sylvain Lebresne wrote:
> On Tue, Jun 25, 2013 at 5:30 AM, Blair Zajac <
> <>> 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 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.


View raw message