[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12901405#action_12901405
]
Jonathan Ellis commented on CASSANDRA-1072:
-------------------------------------------
ISTM that "striping" this way breaks conflict resolution -- if you have two
increments at CL.ONE that update different nodes on the stripe during a
partition, then after the partition heals there's no way to tell that you've
lost an increment similar to the classic read-update-write race. Having a
single node responsible for each shard fixes this problem while still allowing
rudimentary failure tolerance, but has the fragility problems described above.
> Increment counters
> ------------------
>
> Key: CASSANDRA-1072
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1072
> Project: Cassandra
> Issue Type: Sub-task
> Components: Core
> Reporter: Johan Oskarsson
> Assignee: Kelvin Kakugawa
> Attachments: CASSANDRA-1072-2.patch, CASSANDRA-1072-2.patch,
> CASSANDRA-1072.patch, CASSANDRA-1072.patch, Incrementcountersdesigndoc.pdf
>
>
> Break out the increment counters out of CASSANDRA-580. Classes are shared
> between the two features but without the plain version vector code the
> changeset becomes smaller and more manageable.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
