cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Created] (CASSANDRA-6123) Break timestamp ties consistently for a given user requests
Date Tue, 01 Oct 2013 17:27:24 GMT
Sylvain Lebresne created CASSANDRA-6123:
-------------------------------------------

             Summary: Break timestamp ties consistently for a given user requests
                 Key: CASSANDRA-6123
                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6123
             Project: Cassandra
          Issue Type: Bug
            Reporter: Sylvain Lebresne
            Assignee: Sylvain Lebresne
             Fix For: 2.1


The basic goal of this issue is to fix the fact that if 2 different clients issue "simultaneously"
the 2 following updates:
{noformat}
INSERT INTO foo(k, v1, v2) VALUES (0, 1, -1); // client1
INSERT INTO foo(k, v1, v2) VALUES (0, -1, 1); // client2
{noformat}
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.




--
This message was sent by Atlassian JIRA
(v6.1#6144)

Mime
View raw message