[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899015#action_12899015
]
Jeff Darcy commented on CASSANDRA-1072:
---------------------------------------
Sylvain, what does "wait for a number of acks" in your/Kelvin's step 4 mean?
What happens if one or more replicas are on the other side of a partition? What
values are returned while the chosen replica is waiting for acks? It's all very
well to make a "good faith" attempt to reduce the window of inconsistency by
sending updates to other replicas early, but waiting indefinitely seems like
trying to enforce strong consistency and if the wait terminates then we have to
handle the repair after the partition is resolved anyway. This may be the same
objection as Jonathan made at 8pm on August 10, although it covers more cases
than just multi-DC because partitions can and do occur within DCs as well.
Reading the current version vector as part of a write doesn't seem like enough
of a problem to justify complex workarounds, since it's probably in memory
anyway (especially for a hot counter).
> 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.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.
