[CASSANDRA-6123] Break timestamp ties consistently for a given user requests

• Type: New Feature
• Status: Open
• Priority: Normal
• Resolution: Unresolved
• Fix Version/s: 5.x
• Component/s: Legacy/CQL
• Assignee: Unassigned
• Reporter: Sylvain Lebresne
• Created: 01/Oct/13 17:26
• Updated: 07/Mar/23 10:54

Description

The basic goal of this issue is to fix the fact that if 2 different clients issue "simultaneously" the 2 following updates:

INSERT INTO foo(k, v1, v2) VALUES (0, 1, -1); // client1
INSERT INTO foo(k, v1, v2) VALUES (0, -1, 1); // client2

then, if both updates get the same timestamp, then currently, we don't guarantee that at the end the sum of v1 and v2 will be 0 (it won't be in that case).

The idea to solves this is to make sure 2 updates never get the same "timestamp" by making the timestamp be the sum of the current time (and we can relatively easily make sur no 2 update coordinated by the same node have the same current time) and a small ID unique to each server node. We can generate this small unique server id thanks to CAS (see CASSANDRA-6108).

Let's note that this solution is only for server-side generated timestamps. Client provided timestamp will still be allowed, but in that case it will be the job of the client to synchronize to not generate 2 identical timestamp if they care about this behavior.

Note: see CASSANDRA-6106 for some related discussion on this issue.

Issue Links

• is duplicated by: CASSANDRA-8892 Read after write inconsistent even on single-node cluster
• is related to: CASSANDRA-6108 Create timeid64 type
• is related to: CASSANDRA-6178 Consider allowing timestamp at the protocol level ... and deprecating server side timestamps
• is related to: CASSANDRA-6106 Provide timestamp with true microsecond resolution

Sub-Tasks

• Allow Thrift opt-in to server-side timestamps: Resolved