You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@cassandra.apache.org by Daniel Woo <da...@gmail.com> on 2017/10/10 08:22:32 UTC

LWT and non-LWT mixed

The document explains you cannot mix them
http://docs.datastax.com/en/archived/cassandra/2.2/cassandra/dml/dmlLtwtTransactions.html

But what happens under the hood if I do? e.g,

DELETE ....
INSERT ... IF NOT EXISTS

The coordinator has 4 steps to do the second statement (INSERT)
1. prepare/promise a ballot
2. read current row from replicas
3. propose new value along with the ballot to replicas
4. commit and wait for ack from replicas

My question is, once the row is DELETed, the next INSERT LWT should be able
to see that row's tombstone in step 2, then successfully inserts the new
value. But my tests shows that this often fails, does anybody know why?

-- 
Thanks & Regards,
Daniel

Re: LWT and non-LWT mixed

Posted by Anuj Wadehra <an...@yahoo.co.in.INVALID>.
Hi Daniel,
What is the RF and CL for Delete?Are you using asynchronous writes?Are you firing both statements from same node sequentially?Are you firing these queries in a loop such that more than one delete and LWT is fired for same partition?
I think if you have the same client executing both statements sequentially in same thread i.e. one after another and delete is synchronous, it should work fine. LWT will be executed after Cassandra has written on Quorum of nodes and will see the data. Paxos of LWT shall only be initiated when delete completes. 
I think, LWT should not be mixed with normal write when you have such writes fired from multiple nodes/threads on the same partition.

ThanksAnuj
Sent from Yahoo Mail on Android 
 
  On Tue, 10 Oct 2017 at 14:10, Daniel Woo<da...@gmail.com> wrote:   The document explains you cannot mix themhttp://docs.datastax.com/en/archived/cassandra/2.2/cassandra/dml/dmlLtwtTransactions.html

But what happens under the hood if I do? e.g, 
DELETE ....INSERT ... IF NOT EXISTS
The coordinator has 4 steps to do the second statement (INSERT)1. prepare/promise a ballot2. read current row from replicas3. propose new value along with the ballot to replicas4. commit and wait for ack from replicas
My question is, once the row is DELETed, the next INSERT LWT should be able to see that row's tombstone in step 2, then successfully inserts the new value. But my tests shows that this often fails, does anybody know why? 
-- 
Thanks & Regards,
Daniel  

Re: LWT and non-LWT mixed

Posted by Javier Canillas <ja...@gmail.com>.
Daniel,

Cassandra is "eventually consistent". This means that the DELETE can go to
a different coordinator than the INSERT... IF NOT EXISTS. Being so, each
coordinator enters a race condition than can make the INSERT...IF NOT
EXISTS failed reading data that the DELETE will destroy. Even on the same
coordinator, each statement is treated on different threads.

You can play around with CONSISTENCY LEVEL, applying both statements with
ALL may reduce the chance of failure, but it won't make it go away.

What you are willing to do is to "lock" the row on delete, that's something
you can do on SQL engines but not on C*.

Regards,

2017-10-10 5:22 GMT-03:00 Daniel Woo <da...@gmail.com>:

> The document explains you cannot mix them
> http://docs.datastax.com/en/archived/cassandra/2.2/cassandra/dml/
> dmlLtwtTransactions.html
>
> But what happens under the hood if I do? e.g,
>
> DELETE ....
> INSERT ... IF NOT EXISTS
>
> The coordinator has 4 steps to do the second statement (INSERT)
> 1. prepare/promise a ballot
> 2. read current row from replicas
> 3. propose new value along with the ballot to replicas
> 4. commit and wait for ack from replicas
>
> My question is, once the row is DELETed, the next INSERT LWT should be
> able to see that row's tombstone in step 2, then successfully inserts the
> new value. But my tests shows that this often fails, does anybody know why?
>
> --
> Thanks & Regards,
> Daniel
>