Transaction in Cassandra

Cassandra support atomic, isolated, and durable transactions with eventual/tunable consistency. This allow users to decide how strong or eventual they want each transaction’s consistency to be.

Cassandra does not support joins and also does not offer consistency in the ACID sense. Cassandra supports atomicity and isolation at the row-level. Here we will explore the meaning of atomicity, isolation and Durability in terms of Cassandra:

Atomicity

In Cassandra, a write and delete operation is atomic at the partition level. It means that the insertions, or updates of two or more rows in the same partition are treated as one write operation. For example, if the write consistency level is QUORUM and replication factor is 2, Cassandra will replicate the write to all nodes in the cluster and wait for acknowledgement from two nodes. If the write fails on one and succeeds on the other node, Cassandra reports a failure to replicate the write on that node.

Isolation

Write and delete operations in Cassandra are performed on row-level isolation. A write to a row within a single partition on a single node is only visible to the client performing the operation until the operation is complete.

Durability

Before returning as success all writes to a replica node are recorded both in memory and in a commit log on disk. If a crash or server failure occurs before the memtables are flushed to disk, the commit log is replayed on restart to recover any lost writes.

Using lightweight transactions

INSERT and UPDATE statements using the IF clause, support lightweight transactions, also known as Compare and Set (CAS).

Add a new user:

INSERT INTO users (userid, first_name, last_name)
  VALUES ('10', 'Abhay', 'Raj')
  IF NOT EXISTS;