Mailing-List: contact commits-help@cassandra.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cassandra.apache.org
Date: Tue, 26 Mar 2013 13:45:18 +0000 (UTC)
From: "Jonathan Halliday (JIRA)" <jira@apache.org>
To: commits@cassandra.apache.org
Message-ID: <JIRA.12610765.1349638737581.56125.1364305518202@arcas>
In-Reply-To: <JIRA.12610765.1349638737581@arcas>
References: <JIRA.12610765.1349638737581@arcas>
Subject: [jira] [Commented] (CASSANDRA-4775) Counters 2.0
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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

Jonathan Halliday commented on CASSANDRA-4775:
----------------------------------------------

To my mind it's the read rather than the lock that's the problem.  The design pattern of 'blind write to log the event on increment, read and replay the series of events to calculate the current value on read' would seem more in keeping with the 'cassandra way'. Of course you need to periodically squash the increment log down to a single point in time value to stop it growing unbounded and that step does need locking of some form, but that batch operation is less costly than a lock/read on each write.  In keeping with my earlier point re: making the 'counters' mechanism as general/pluggable as possible, having a generic implementation of the 'log a modification event stream, replay it on read' that could eventually be exposed as a primitive on which users could build their own functionality would be a big win. It may be a harder pattern to implement well, but it's ultimately a lot more powerful.
                
> 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
>              Labels: counters
>             Fix For: 2.0
>
>
> 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