cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tyler Hobbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-10981) Consider striping view locks by key and cfid
Date Fri, 08 Jan 2016 18:20:39 GMT

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

Tyler Hobbs commented on CASSANDRA-10981:
-----------------------------------------

Okay, I've pushed a second commit to the same branch that uses the simpler CounterMutation-like
approach of building the lock key.

> 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
>            Priority: Minor
>             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)

Mime
View raw message