Database Reference
In-Depth Information
The key fact about this optimistically locked update is that we do two things with the
version
column. First, we use a conditional update to instruct Cassandra to only per-
form the update if the version is the same as it was when the user initiated the update. Se-
cond, in the same query, we change the
version
column to a new value. Taken together,
these two interactions with the
version
column ensure that we cannot unwillingly over-
write changes made by another user to the same row.
On checking the relevant columns in the
users
table, we see that both the
location
and
version
columns have been updated:
Now, let's see how our system behaves in the case of concurrent updates by different
users. The situation we're most concerned about is the one in which a second user of the
system also tries to update HappyCorp's location, and initiates the process
before
the up-
date we just performed is completed. From the perspective of this second updater, the
location
field is blank, and we know that the version we've read is the original version,
ec0c1fb1-321f-11e4-8eeb-5f98e903bf02
.
So, when the second updater tries to save their work, we'll once again make the update
conditional on finding the version number we started with:
UPDATE "users"
SET "location" = 'Palo Alto, CA', "version" = NOW()
WHERE "username" = 'happycorp'
IF "version" = ec0c1fb7-321f-11e4-8eeb-5f98e903bf02;
From a bird's-eye view of this process, we know that this update will not be applied be-
cause the process that updated the
location
value to
New York
also changed the
version
. However, the process that's trying to make the change to
Palo Alto
doesn't
need to know this fact; it can simply ask Cassandra to make the update conditional on
finding the right version, and Cassandra will do the right thing no matter what. In this
case, we see that the update is indeed not applied:
