[
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
