cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jeff Darcy (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1072) Increment counters
Date Mon, 16 Aug 2010 21:48:26 GMT

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

Jeff Darcy commented on CASSANDRA-1072:
---------------------------------------

If I'm reading this correctly, then the prior approach would have required reading at CL.ALL
to get a consistent result and this reduces it to CL.QUORUM instead.  At least, that's the
only way I can reconcile "lift
some of (what I believe to be) the main limitation" from August 10 with both "handling better
network partitions" and "exact same behavior and consistency" today.  Is that correct?  If
it is, let's look at the simultaneous-write case some more.  Let's say two nodes get updates
at the exact same instant, both at CL.QUORUM.  A reader at CL.QUORUM will therefore see at
least one value reflecting each of those updates.  If that reader does see inconsistent values,
how will it reconcile them?  In particular, if it sees A=10/B=11/C=12 from three replicas,
how will it distinguish between the following?

(a) Initial value was 10, B got a +1 which hasn't propagated, C got a +2 which hasn't propagated
-> reconciliation should yield 13.
(b) Initial value was 10, B got a +1 which propagated to C but not A, C got a +1 which hasn't
propagated at all -> reconciliation should yield 12.

I'm not trying to poke holes here; I'm just curious because I don't see clearly how the scheme
you laid out would handle this case.

> 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.


Mime
View raw message