[
https://issues.apache.org/jira/browse/CASSANDRA-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jonathan Ellis updated CASSANDRA-6123:
--------------------------------------
Fix Version/s: (was: 2.1 rc1)
3.0
Issue Type: New Feature (was: Bug)
> 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
> Reporter: Sylvain Lebresne
> Assignee: Sylvain Lebresne
> Fix For: 3.0
>
>
> 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.2#6252)
