[ https://issues.apache.org/jira/browse/CASSANDRA-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17154367#comment-17154367 ]
ZhaoYang commented on CASSANDRA-10307: -------------------------------------- the lock contention issue will not be a problem in thread-per-core architecture, but the lock is still needed to prevent racing with the previous insertion that is waiting for async io from read-before-write. > Avoid always locking the partition key when a table has a materialized view > --------------------------------------------------------------------------- > > Key: CASSANDRA-10307 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10307 > Project: Cassandra > Issue Type: Improvement > Components: Feature/Materialized Views > Reporter: T Jake Luciani > Priority: Normal > Labels: materializedviews > Fix For: 4.x > > > When a table has associated materialized views we must restrict other > concurrent changes to the affected rows. We currently lock the entire > partition. > The issue is many updates to the same partition on the base table is now > serialized effectively. > We can't lock the primary key instead due to range tombstones cover a range > of rows. > If we created (or perhaps reuse if already exists) a clustering range class > we can lock at this level. -- This message was sent by Atlassian Jira (v8.3.4#803005) --------------------------------------------------------------------- To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org For additional commands, e-mail: commits-h...@cassandra.apache.org