[
https://issues.apache.org/jira/browse/CASSANDRA-10981?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15088223#comment-15088223
]
Tyler Hobbs commented on CASSANDRA-10981:
-----------------------------------------
Patch and (pending) test runs:
|[CASSANDRA-10981|https://github.com/thobbs/cassandra/tree/CASSANDRA-10981]|[testall|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-10981-testall]|[dtest|http://cassci.datastax.com/view/Dev/view/thobbs/job/thobbs-CASSANDRA-10981-dtest]|
I've also created [a new
dtest|https://github.com/riptano/cassandra-dtest/pull/736] to focus on
single-partition contention.
> Consider striping view locks by key and cfid
> --------------------------------------------
>
> Key: CASSANDRA-10981
> URL: https://issues.apache.org/jira/browse/CASSANDRA-10981
> Project: Cassandra
> Issue Type: Improvement
> Components: Coordination
> Reporter: Tyler Hobbs
> Assignee: Tyler Hobbs
> Fix For: 3.x
>
>
> We use a striped lock to protect updates to tables with materialized views,
> and the lock is currently striped by the partition key of the {{Mutation}}.
> This causes concurrent updates to separate tables with the same partition key
> to contend for the same lock, resulting in one or more of the mutations being
> rescheduled on the {{MUTATION}} threadpool (potentially becoming an
> asynchronous operation instead a synchronous operations, from the perspective
> of local internal modifications).
> Since it's probably fairly common to use the same partition key across
> multiple tables, I suggest that we add the cfid of the affected table to the
> lock striping, and acquire one lock per affected table (with the same
> rescheduling-under-contention behavior).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
