On 6/26/13 10:26 AM, Sylvain Lebresne wrote:
On Tue, Jun 25, 2013 at 5:30 AM, Blair Zajac <bl...@orcaware.com
<mailto: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.
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
