[
https://issues.apache.org/jira/browse/CASSANDRA-1072?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12899037#action_12899037
]
Sylvain Lebresne commented on CASSANDRA-1072:
---------------------------------------------
You left an important part of the sentence. This important part is 'that
depends on CL'. Of course network partitions can occur. Actually what I'm
proposing is all about handling better network partitions. It aims to establish
the exact same behavior and consistency level insurances that Cassandra already
ensures. The 'number of acks' will be equal to what you, the client issuing the
write, ask for when specifying the consistency level.
Moreover I've never suggested wait indefinitely. Again, it that wasn't clear is
really just what Cassandra already do, that is, send the update to all replica
and wait for only as many responses as the client has asked you to. Sorry if
that wasn't clear.
As for the last sentence of you comment, I'm not sure I understand it. But I
sure don't meant to propose a complex workarounds, quite the contrary, and
right now, I think this is neither really complex, nor a workaround as this
addresses real problems.
But don't get me wrong, I appreciate your questions/concerns as there could
very well be something wrong in my reasoning.
> 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.
