cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Javier Canillas <>
Subject Re: LWT and non-LWT mixed
Date Tue, 10 Oct 2017 12:43:24 GMT

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*.


2017-10-10 5:22 GMT-03:00 Daniel Woo <>:

> The document explains you cannot mix them
> dmlLtwtTransactions.html
> But what happens under the hood if I do? e.g,
> DELETE ....
> 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

View raw message