Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Wed, 9 Oct 2013 12:24:44 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12671625.1380648388794.38100.1381321484332@arcas>
In-Reply-To: <JIRA.12671625.1380648388794@arcas>
References: <JIRA.12671625.1380648388794@arcas>
Subject: [jira] [Commented] (CASSANDRA-6123) Break timestamp ties
 consistently for a given user requests
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/CASSANDRA-6123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13790294#comment-13790294 ] 

Jonathan Ellis commented on CASSANDRA-6123:
-------------------------------------------

Where does that limitation come from?  We were looking at a 16-bit server ID.

> 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)