In Cassandra, linearizable consistency is supported by lightweight transactions (LWTs). They have the same syntax as CQL statements INSERT, UPDATE and DELETE with additional IF clauses:

INSERT INTO ... VALUES ...
IF NOT EXISTS;

UPDATE ... SET ... WHERE ...
IF EXISTS | IF predicate [ AND ... ];

DELETE ... FROM ... WHERE ...
IF EXISTS | IF predicate [ AND ... ];

The IF clauses specify conditions that must be satisfied for inserts, updates and deletes to succeed. Thus, lightweight transactions are also sometimes referred to as compare-and-set operations. Each lightweight transaction is atomic and always works on a single partition.

Start the CQL shell:

cqlsh

Create the keyspace:

CREATE KEYSPACE killr_video
WITH replication = {
  'class': 'NetworkTopologyStrategy', 
  'DC-Houston': 1 };

Set the current working keyspace:

USE killr_video;

In our first example, we use lightweight transactions to register new users. This scenario demonstrates how two people, Joe and Jen, try to register new accounts using the same username dragonslayer. Only one registration should succeed.

Create the table:

CREATE TABLE users (
  username TEXT,
  email TEXT,
  name TEXT,
  password TEXT,
  reset_token UUID,
  PRIMARY KEY ((username))
);

Register the users:

INSERT INTO users (username, email, name) 
VALUES ('dragonslayer', '[email protected]', 'Joe')
IF NOT EXISTS;
INSERT INTO users (username, email, name) 
VALUES ('dragonslayer', '[email protected]', 'Jen')
IF NOT EXISTS;

Retrieve the new account:

SELECT * FROM users
WHERE username = 'dragonslayer';

In our second example, we use lightweight transactions to reset a user password. This scenario assumes that the user with username dragonslayer requests to reset his password. Our application generates a random reset token that expires in 1 hour or 3600 seconds and can be used only once. A subsequent attempt to use the same token should fail.

Generate a password reset token:

UPDATE users USING TTL 3600
SET reset_token = 6ef95fd0-9ae0-11ea-a9d2-d777ab7dec9e 
WHERE username = 'dragonslayer';

SELECT * FROM users
WHERE username = 'dragonslayer';

Update the password:

UPDATE users 
SET reset_token = null, password = 'encrypted password'
WHERE username = 'dragonslayer'
IF reset_token = 6ef95fd0-9ae0-11ea-a9d2-d777ab7dec9e;

UPDATE users 
SET reset_token = null, password = 'malicious password'
WHERE username = 'dragonslayer'
IF reset_token = 6ef95fd0-9ae0-11ea-a9d2-d777ab7dec9e;

Retrieve the user information:

SELECT * FROM users
WHERE username = 'dragonslayer';

In our third example, we use lightweight transactions to implement rules for changing an order status:

• status can change to shipped only from awaiting shipment
• status can change to cancelled only from awaiting payment or awaiting shipment

This scenario assumes that our dragonslayer user has two orders in the system with statuses awaiting payment and awaiting shipment. While a shipping department attempts to ship the orders, the user attempts to cancel them. The order statuses should change to cancelled and shipped, respectively.

Create the table and two orders:

CREATE TABLE orders_by_user (
  username TEXT,
  order_id UUID,
  status TEXT,
  PRIMARY KEY ((username), order_id)
);

INSERT INTO orders_by_user (username, order_id, status) 
VALUES ('dragonslayer', f1fa2590-2d78-4b77-9710-95bdb45b7fa1, 'awaiting payment');
INSERT INTO orders_by_user (username, order_id, status) 
VALUES ('dragonslayer', c420d3a3-cecc-4c25-a7f8-ef28eb532969, 'awaiting shipment');
SELECT * FROM orders_by_user WHERE username = 'dragonslayer';

Ship the orders:

Cancel the orders:

Retrieve the orders:

SELECT * FROM orders_by_user
WHERE username = 'dragonslayer';

Our fourth example deals with transactions that place bids on auction items. This scenario demonstrates how two users, dragonslayer and delossailor, bid on the same item.

Create the table and add the item:

CREATE TABLE auction_items (
  item_id TEXT,
  starting_bid DECIMAL,
  highest_bid DECIMAL,
  highest_bidder TEXT,
  PRIMARY KEY ((item_id))
);

INSERT INTO auction_items (item_id, starting_bid, highest_bid) 
VALUES ('ABC123', 10.00, 0.00);
SELECT * FROM auction_items WHERE item_id = 'ABC123';

User dragonslayer bids $10.00:

User delossailor bids $10.00:

User delossailor bids $10.99:

Our final and a bit more advanced example deals with transactions that place bids on auction items just like in the previous example. However, to make things even more realistic, we also keep the history of all placed bids, whether they were successful or not.

Create the table and add the item:

CREATE TABLE bids_by_item (
  item_id TEXT,
  bid_id TIMEUUID,
  bid DECIMAL,
  bidder TEXT,
  starting_bid DECIMAL STATIC,
  highest_bid DECIMAL STATIC,
  highest_bidder TEXT STATIC,
  PRIMARY KEY ((item_id), bid_id)
) WITH CLUSTERING ORDER BY (bid_id DESC);

INSERT INTO bids_by_item (item_id, bid_id, starting_bid, highest_bid) 
VALUES ('ABC123', NOW(), 10.00, 0.00);
SELECT * FROM bids_by_item WHERE item_id = 'ABC123';

User dragonslayer bids $10.00:

INSERT INTO bids_by_item (item_id, bid_id, bid, bidder) 
VALUES ('ABC123', NOW(), 10.00, 'dragonslayer');

UPDATE bids_by_item 
SET highest_bid = 10.00, highest_bidder = 'dragonslayer' 
WHERE item_id = 'ABC123'
IF starting_bid <= 10.00 AND highest_bid < 10.00;
SELECT * FROM bids_by_item WHERE item_id = 'ABC123';

User delossailor bids $10.00:

User delossailor bids $10.99:

In terms of performance, lightweight transactions can be several times slower than regular inserts, updates and deletes, which is the consequence of using the Paxos consensus protocol for the internal implementation. Therefore, you should only use lightweight transactions when it is absolutely necessary.

You should be able to recognize potential race conditions and estimate data contention. In case of low data contention, when only a few transactions compete for access to the same data, using lightweight transactions to enforce linearizable consistency is a good choice. However, in case of high data contention, when many concurrent transactions compete for access to the same data, you may be better off changing your data model to reduce data contention or organize transactions into a time-ordered queue to ensure serial execution.

With respect to our previous examples, registering new users, resetting user passwords, and shipping and cancelling orders clearly fall into the low data contention category. The example of bidding on auction items can potentially have high data contention.

Here is a short quiz for you.