How to executing batch statement and LWT as a transaction in Cassandra

Question

I have two table with below model:

CREATE TABLE IF NOT EXISTS INV (
  CODE TEXT,
  PRODUCT_CODE TEXT,
  LOCATION_NUMBER TEXT,
  QUANTITY DECIMAL,
  CHECK_INDICATOR BOOLEAN,
  VERSION BIGINT,
PRIMARY KEY ((LOCATION_NUMBER, PRODUCT_CODE)));

CREATE TABLE IF NOT EXISTS LOOK_INV (
  LOCATION_NUMBER TEXT,
  CHECK_INDICATOR BOOLEAN,
  PRODUCT_CODE TEXT,
  CHECK_INDICATOR_DDTM TIMESTAMP,
PRIMARY KEY ((LOCATION_NUMBER), CHECK_INDICATOR, PRODUCT_CODE))
WITH CLUSTERING ORDER BY (CHECK_INDICATOR ASC, PRODUCT_CODE ASC);

I have a business operation where i need to update CHECK_INDICATOR in both the tables and QUANTITY in INV table. As CHECK_INDICATOR is a part of key in LOOK_INV table, i need to delete the row first and insert a new row. Below are the three operations i need to perform in batch fashion (either all will be executed sucessfully or none should be executed)

1. Delete row from LOOK_INV table.
2. Insert row in LOOK_INV table.
3. Update QUANTITY and CHECK_INDICATOR in INV table.

As INV table is getting access by multiple threads, i need to make sure before updating INV table row that it has not been changed since last read. I am using LWT transaction to update INV table using VERSON column and batch operation for deletion and insertion in LOOK_INV table.I want to add all the three operation in batch.But since LWT is not acceptable in batch i need to execute in aforesaid fashion.

The problem with this approach is that in some scenario batch get executed sucessfully but updating INV table results in timeout exception and data become incosistent in both the table.

Is there any feature provided by cassandra to handle these type of scenario elegantly?

Answer 1

Caution with Lightweight Transactions (LWT)

Lightweight Transactions are currently considered a Cassandra anti-pattern because of the performance issues you are suffering.

Here is a bit of context to explain.

Cassandra does not use RDBMS ACID transactions with rollback or locking mechanisms. It does not provide locking because of a fundamental constraint on all kinds of distributed data store called the CAP Theorem. It states that it is impossible for a distributed computer system to simultaneously provide all three of the following guarantees:

• Consistency (all nodes see the same data at the same time)
• Availability (a guarantee that every request receives a response about whether it was successful or failed)
• Partition tolerance (the system continues to operate despite arbitrary message loss or failure of part of the system)

Because of this, Cassandra is not good for atomic operations and you should not use Cassandra for this purpose.

It does provide lightweight transactions, which can replace locking in some cases. But because the Paxos protocol (the basis for LWT) involves a series of actions that occur between nodes, there will be multiple round trips between the node that proposes a LWT and the other replicas that are part of the transaction.

This has an adverse impact on performance and is one reason for the WriteTimeoutException error. In this situation you can't know if the LWT operation has been applied, so you need to retry it in order to fallback to a stable state. Because LWTs are so expensive, the driver will not automatically retry it for you.

LTW comes with big performance penalties if used frequently, and we see some clients with big timeout issues due to using LWTs.

Lightweight transactions are generally a bad idea and should be used infrequently.

If you do require ACID properties on part of your workload but still require it to scale , consider shifting that part of your load to cochroach BD. In summary, if you do need ACID transactions it is generally a lot easier to bring a second technology in.