[
https://issues.apache.org/jira/browse/CASSANDRA-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13958711#comment-13958711
]
Benedict commented on CASSANDRA-6880:
-------------------------------------
+1
Pushed a [slightly modified
version|https://github.com/belliottsmith/cassandra/tree/6880]
I've changed wrapCounterCells: renamed it to make it clearer what it's for from
the name alone, and instead of writing our own Iterable/Iterator/Object, use
Guava transformations. Also don't allocate a special object with a specialised
hashCode(), simply let the hashCode() get boxed into an Integer, which is
functionally equivalent but a bit neater in my book.
Don't feel super strongly about the changes if you still prefer your approach
though.
> counters++ lock on cells, not partitions
> ----------------------------------------
>
> Key: CASSANDRA-6880
> URL: https://issues.apache.org/jira/browse/CASSANDRA-6880
> Project: Cassandra
> Issue Type: Improvement
> Reporter: Aleksey Yeschenko
> Assignee: Aleksey Yeschenko
> Fix For: 2.1 beta2
>
>
> I'm starting to think that we should switch to locking by cells, not by
> partitions, when updating counters.
> With the current 2.1 counters, if nothing changes, the new recommendation
> would become "use smaller partitions, batch updates to the same partition",
> and that goes against what we usually recommend:
> 1. Prefer wide partitions to narrow partitions
> 2. Don't batch counter updates (because you risk to exaggerate
> undercounting/overcounting in case of a timeout)
> Locking on cells would cause C* to have to grab more locks for batch counter
> updates, but would give us generally more predictable performance
> (independent of partition wideness), and won't force people to remodel their
> data model if they have often concurrently-updated counters in the same few
> wide partitions.
> (It's a small change, code-wise)
--
This message was sent by Atlassian JIRA
(v6.2#6252)
