cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nicholas Wilson <>
Subject How are timestamps selected for LWTs?
Date Tue, 02 Feb 2016 09:46:08 GMT

In the Cassandra docs I've read, it's not described how the timestamp is determined for LWTs.
It's not possible to specify a timestamp with "USING TIMESTAMP ...", and my best guess is
that in the "read" phase of the LWT (between propose and commit) the timestamp is selected
based on the timestamps of the cells read. However, after reading through the source code
(mainly StorageProxy::cas) I can't any hint of that.

I'm worried about the following problem:

Node A writes (using a LWT): UPDATE table SET val = 123, version = 2 WHERE key = 'foo' IF
version = 1
Node B writes (using a LWT): UPDATE table SET val = 234, version = 3 WHERE key = 'foo' IF
version = 2

If the first write is completed before the second, then both updates will be applied, but
if Node B's clock is behind Node A's clock, then the second update would be effectively discarded
if client-generated timestamps are used. It wouldn't take a big clock discrepancy, the HW
clocks could in fact be perfectly in sync, but if the kernel ticks System.currentTimeMillis()
at 15ms intervals it's quite possible for the two nodes to be 30ms out from each other.

So, after the update query has "succeeded", do you need to do a read to find out whether it
was actually applied? That would be surprising, since I can't find mention of it anywhere
in the docs. You'd actually have to do a QUORUM read after every LWT update, just to find
out whether your client chose the timestamp sensibly.

The ideal thing would be if Cassandra chose the timestamp for the write, using the timestamp
of the cells read during Paxos, to guarantee that writes are applied if the query condition
holds, rather than leaving the potential for the query to succeed but do nothing if the cell
already has a higher timestamp.

If I've misunderstood, please do correct me!


Nicholas Wilson
Software developer
View raw message