Row Based Transaction in Cassandra

1.  Cassandra has atomicity enabled at the row level, which means that inserting or updating columns in a row is treated as one write operation.An example can be treating all updates as new inserts as new columns added against the same row.

2. Cassandra supports full row-level isolation, which means that writes to a row are isolated to the client performing those writes and not visible to any other user until they are complete.

3. All writes to a replica node are recorded on disk before being acknowledged as successful. The commit log can be replayed on restart to receive any lost writes in case there is a crash or server failure before the memory tables are flushed to disks.

4. In fact, Cassandra does not support transactions in the sense of bundling multiple row updates into one all-or-nothing operation. It will also not roll back when a write succeeds on one replica, but fails on other replicas.

5. The lightweight transaction support is similar to RDBMS support for certain use cases, which require linearizable consistency or in ACID terms, a serial isolation level. A serial consistency level allows us to read the current (and possibly uncommitted) state of data without proposing a new addition or update. If a serial read finds an uncommitted transaction in progress, it will commit it as part of the read.

6. The lightweight transaction is similar to the "compare and set" operation and involves the new IF clause added to the INSERT and UPDATE commands in CQL. 
The usage of lightweight transactions involves quorum-based operations and updates will incur a performance hit with degradation by one-third of the normal operation.