question

376752150_179413 avatar image
376752150_179413 asked 376752150_179413 commented

Why can mixing lightweight transactions and normal operations result in errors?

The doc says:

Lightweight transactions use a timestamping mechanism different from normal operations, so mixing lightweight transactions and normal operations can result in errors. If lightweight transactions are used to write to a row within a partition, only lightweight transactions for both read and write operations should be used. This caution applies to all operations, whether individual or batched.

For example, the following series of operations can fail:

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

The following series of operations will work:

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


Does it mean 

 insert into compain(id, day) values(1,1) if not exists;
 delete from compain where id = 1
 insert into compain(id, day) values(1,1) if not exists;

No matter whether in a batch or not, the 2nd insert will not be applied? Why delete is not visible to the 2nd insert?

Why does using different timestamping mechanisms result in errors? And what kind of errors?



lwt
10 |1000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

1 Answer

Lewisr650 avatar image
Lewisr650 answered 376752150_179413 commented

The broader implication to the query patterns you outline has to do with the consistency level being executed on the transaction. Mixing this series in a short time window may expose the replication consistency across the cluster. If you have a replication factor of 3, then only 3 nodes are involved in a transaction at any given time. If you Delete data with consistency level of "Quorum" or "Local_Quorum" that means the coordinator only requires 2 acknowledgements form the nodes to move forward. The lightweight transaction will perform a distributed lock using paxos to validate consistency of the data by performing a read before write to validate the data on each of the 3 nodes. You still have a window of opportunity where that 3 node that did not respond to the previous delete and may have inconsistent data due to workload, being overwhelmed, compaction or repair operations imposing on the node. In that scenario, which would likely be rare in a healthy cluster, would still have an old value (not deleted the data yet) and therefore serve the old value. However, you could manage the situation in two ways:

1) Maintain a healthy, highly performant cluster without bottlenecks

2) Validate the data through higher consistency level management such as CL=ALL on the delete.

1 comment Share
10 |1000
Toggle Comment visibility. Current Visibility: Viewable by all users

Up to 8 attachments (including images) can be used with a maximum of 1.0 MiB each and 10.0 MiB total.

376752150_179413 avatar image 376752150_179413 commented ·

thanks for replying! The doc seems a little confusing, I still cannot understand what's the business of timestamp here....

And from the doc literally meaning, does it mean that if all the query should lwt, or else non-lwt, no only the queries in the same batch...

0 Likes 0 ·