[
https://issues.apache.org/jira/browse/CASSANDRA-4775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13702071#comment-13702071
]
Sylvain Lebresne commented on CASSANDRA-4775:
---------------------------------------------
bq. So we'd lock even before the commitlog entry?
Yes. The SP.applyCounterMutationOnLeader would become something like (on just
one counter to make it simpler):
{noformat}
public AbstractWriteResponseHandler applyCounterMutationOnLeader(CFStore cfs,
ByteBuffer key, CounterUpdateColumn increment)
{
counterLock.lock();
try
{
CounterColumn current = read(cfs, key, column.name());
CounterColumn newValue = current.add(increment); // This would return a
new value where the current node shard has an incremented value and clock
cfs.apply(newValue);
}
finally
{
counterLock.unlock();
}
}
{noformat}
(of course in practice we would "shard" that counterLock, and there is probably
some fancier optimization to do).
> 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
> Assignee: Aleksey Yeschenko
> Labels: counters
> Fix For: 2.1
>
>
> 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
