[ https://issues.apache.org/jira/browse/CASSANDRA-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
C. Scott Andreas updated CASSANDRA-6123: ---------------------------------------- Component/s: CQL > 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: New Feature > Components: CQL > Reporter: Sylvain Lebresne > Priority: Major > Fix For: 4.x > > > 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 (v7.6.3#76005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org