What are the implications of using lightweight transactions?

Question

In particular I was looking at this page where it says:

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.

I'm confused as to what using LWTs for read operations looks like. Specifically how this relates to per-query consistency (and serialConsistency) levels.

The description for SERIAL read consistency raises further questions:

Allows reading the current (and possibly uncommitted) state of data without proposing a new addition or update.

That suggests that using SERIAL for reads is not "using a LWT".

But then

• How does Cassandra know to check for in-progress transactions when you do a read?
• What is the new update that is proposed while you're trying to read, and how does this affect the read?
• How would that work if the consistency you're reading at (say ONE for example) is less than the serialConsistency used for writing?
• Once you use a LWT on a table (or row?, or column?), are all non-SERIAL reads forced to take the penalty of participating in quorums and the transaction algorithm?
• Does the requirement actually apply to the whole row, or just the columns involved in the conditional statement?

If I ignore this advice and make both serial and non-serial reads/writes. In what way to the LWTs fail?

Answer 1

How does Cassandra know to check for in-progress transactions when you do a read?

This is exactly what the SERIAL consistency level indicates. It makes sure that a query will only return results after all pending transactions have been fully executed.

What is the new update that is proposed while you're trying to read, and how does this affect the read?

I think what the doc is trying to say is that the read will be handled just like a LWT - just without make any updates on it's own.

How would that work if the consistency you're reading at (say ONE for example) is less than the serialConsistency used for writing?

Reads using SERIAL will always imply QUORUM as consistency level. Reading with ONE will not provide you any guarantees provided by SERIAL and you can end up reading stalled data.

Once you use a LWT on a table (or row?, or column?), are all non-SERIAL reads forced to take the penalty of participating in quorums and the transaction algorithm?

No. You can use non-SERIAL consistency levels for your queries and have them executed with the exact same performance characteristics as any other non-serial queries.

Does the requirement actually apply to the whole row, or just the columns involved in the conditional statement?

No, I think you should be fine as long as you use different columns for serial reads/writes (including conditions) and regular reads/writes.

If I ignore this advice and make both serial and non-serial reads/writes. In what way to the LWTs fail?

If you execute regular writes, not being executed as part of a LWT, those writes will be applied at any time, without interfering at all with the consensus process of LWTs. As a consequence, regular writes can in theory change a value that is part of a LWT condition at a time between evaluating the condition and applying the update, which is a potential cause for inconsistencies you wanted to avoid using LWTs.