[
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: [email protected]
For additional commands, e-mail: [email protected]
