[jira] [Commented] (CASSANDRA-6507) counters++ get rid of logical clock in global shards

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

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

Sylvain Lebresne commented on CASSANDRA-6507:
---------------------------------------------

I think I'm not sure about this one. Or at least:
* if/when we do CASSANDRA-6506, the clock becomes the cell timestamp and we don't have to have any special reconciliation rule for counter cells (which will thus be entirely normal cell). If we do this ticket, it's not true anymore, reconciliation will remain based on the cell value and we'll still need to have special reconciliation rules.
* it feels like the code we'll need while we switch to that will be pretty ugly (since basically the new global shard would have 2 counts while the old one will still have count and clock, and both will sometimes be in the same context). Plus we'd need to be extra careful about the merge rules between old and new shard. Very probably doable, but likely a tad ugly.
* saying that this would make CASSANDRA-4417 impossible is a bit disingenuous. If we were using a increment+decrement today, this wouldn't make the underlying problems of CASSANDRA-4417 go away and we'd still end up with potentially corrupted counters. The only difference might be that we wouldn't have a good way to detect it and log an error, but that's hardly an advantage.


> counters++ get rid of logical clock in global shards
> ----------------------------------------------------
>
>                 Key: CASSANDRA-6507
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6507
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: Aleksey Yeschenko
>            Assignee: Aleksey Yeschenko
>            Priority: Minor
>             Fix For: 2.1
>
>
> In CASSANDRA-6504 the global shards still follow the {count, logical clock} pattern of the legacy shards. We could store the {increments, decrements} tuple in the shard instead, and for reconcile, instead of relying on the logical clock, pick the largest value of `increments` and `decrements` of the two shards, and use that.
> E.g., shard1: {2000, 1001} (total 999), shard2: {2001, 1000} (total 1001). reconciled = {max(2000, 2001), max(1001, 1000)} = {2001, 1001} (total 1000).
> While scenarios like this generally shouldn't happen post CASSANDRA-6504, this change costs us nothing, and makes issues like CASSANDRA-4417 theoretically impossible	. This also makes our new implementation directly follow the http://hal.inria.fr/docs/00/55/55/88/PDF/techreport.pdf white paper.



--
This message was sent by Atlassian JIRA
(v6.1.4#6159)