[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13702042#comment-13702042
]
Sylvain Lebresne commented on CASSANDRA-4775:
---------------------------------------------
We currently have 2 types of shards in a couter context: local and remotes.
Remote ones are resolved using a "the biggest-clock wins" rule so they are not
problem for internal idempotence. The problem are local shards: when a new
increment comes int, the "leader" of that increment writes a new cell with that
increment as local shard, and those local shard get summed during merge. That's
the problem, since duplicating said shard imply a duplicate count.
But those local shards are an implementation detail. The idea of doing a
read-before-write imply not using those anymore. So on a new increment, the
"leader" of the increment would read the current value for his own shard,
compute the increment value (and incremented clock) and write that result. But
it's now the result of the increment (for his own shard, other node can safely
increment their own shard concurrently), not an increment. So duplicating those
cells doesn't matter at all. It does mean you synchronize locally the
read-before-write of course, hence my mentioning of locking above.
Make sense?
> Counters 2.0
> ------------
>
> Key: CASSANDRA-4775
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4775
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Arya Goudarzi
> Assignee: Aleksey Yeschenko
> Labels: counters
> Fix For: 2.1
>
>
> The existing partitioned counters remain a source of frustration for most
> users almost two years after being introduced. The remaining problems are
> inherent in the design, not something that can be fixed given enough
> time/eyeballs.
> Ideally a solution would give us
> - similar performance
> - less special cases in the code
> - potential for a retry mechanism
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
