Locking is a complicated problem for distributed systems. It also usually leads to slow operations.
Implementing locks in Cassandra has been considered and decided against. You can see the history, conversation, and ultimate resolution in this Jira –
https://issues.apache.org/jira/browse/CASSANDRA-5062.
So cassandra went ahead with Paxos
The Paxos consensus protocol allows a distributed system to agree on proposals with a quorum-based algorithm, with no masters required and without the problems of two-phase commit. There are two phases to Paxos: prepare/promise, and propose/accept.
Prepare/promise is the core of the algorithm. Any node may propose a value; we call that node the leader. (Note that many nodes may attempt to act as leaders simultaneously! This is not a “master” role.) The leader picks a ballot and sends it to the participating replicas. If the ballot is the highest a replica has seen, it promises to not accept any proposals associated with any earlier ballot. Along with that promise, it includes the most recent proposal it has already received.
If a majority of the nodes promise to accept the leader’s proposal, it may proceed to the actual proposal, but with the wrinkle that if a majority of replicas included an earlier proposal with their promise, then that is the value the leader must propose. Conceptually, if a leader interrupts an earlier leader, it must first finish that leader’s proposal before proceeding with its own, thus giving us our desired linearizable behavior.
Implementing locks in Cassandra has been considered and decided against. You can see the history, conversation, and ultimate resolution in this Jira –
https://issues.apache.org/jira/browse/CASSANDRA-5062.
- There are some external options that allow to do some locking over cassandra (i.e. hector and others) but these are suboptimal solutions
So cassandra went ahead with Paxos
The Paxos consensus protocol allows a distributed system to agree on proposals with a quorum-based algorithm, with no masters required and without the problems of two-phase commit. There are two phases to Paxos: prepare/promise, and propose/accept.
Prepare/promise is the core of the algorithm. Any node may propose a value; we call that node the leader. (Note that many nodes may attempt to act as leaders simultaneously! This is not a “master” role.) The leader picks a ballot and sends it to the participating replicas. If the ballot is the highest a replica has seen, it promises to not accept any proposals associated with any earlier ballot. Along with that promise, it includes the most recent proposal it has already received.
If a majority of the nodes promise to accept the leader’s proposal, it may proceed to the actual proposal, but with the wrinkle that if a majority of replicas included an earlier proposal with their promise, then that is the value the leader must propose. Conceptually, if a leader interrupts an earlier leader, it must first finish that leader’s proposal before proceeding with its own, thus giving us our desired linearizable behavior.
Lightweight transactions in CQL
Lightweight transactions can be used for both INSERT and UPDATE statements, using the new IF clause. Here’s an example of registering a new user:INSERT INTO USERS (login, email, name, login_count)
values ('jbellis', 'jbellis@datastax.com', 'Jonathan Ellis', 1)
IF NOT EXISTS
And an an example of resetting his password transactionally:UPDATE users
SET reset_token = null, password = ‘newpassword’
WHERE login = ‘jbellis’
IF reset_token = ‘some-generated-reset-token’
Important Points about cassandra LWT(Light weight Tansactions)
- LWTs are, by definition, slower than regular insert/update statements in Cassandra and are designed to be used for a minority of use cases. 1% of your workload.
- LWTs only work inside a partition. Cross partition inserts will not block LWTs.