[jira] [Comment Edited] (CASSANDRA-17071) Relax schema synchronization when opening a keyspace

["Jacek Lewandowski (Jira)" <ji...@apache.org>]

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

Jacek Lewandowski edited comment on CASSANDRA-17071 at 11/24/21, 9:20 AM:
--------------------------------------------------------------------------

||PR||j11||
|​[trunk|https://github.com/apache/cassandra/pull/1331]|[(/)|https://app.circleci.com/pipelines/github/jacek-lewandowski/cassandra/141/workflows/d2416e08-1e4c-44df-a411-53a4fd4ef4ea]


was (Author: jlewandowski):
||PR||
|​[trunk|https://github.com/apache/cassandra/pull/1331]|

> Relax schema synchronization when opening a keyspace
> ----------------------------------------------------
>
>                 Key: CASSANDRA-17071
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-17071
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Cluster/Schema
>            Reporter: Jacek Lewandowski
>            Assignee: Jacek Lewandowski
>            Priority: Normal
>          Time Spent: 1h 40m
>  Remaining Estimate: 0h
>
> Extracted this as a separate ticket per discussion on CASSANDRA-17044
> In short, there are two purposes of this change:
> # Move the code around to the more appropriate places (for example, CFS specific code for dropping table was moved from SM class to CFS class)
> # Relax the synchronization when adding/removing keyspace instances in SM - instead of synchronizing the whole collection of keyspace instances, we only synchronize the related item (the original idea authored by [~blambov]). 
> The current implementation works because a certain order of opening keyspaces is assumed. If a keyspace is already initialized, it is just returned without sync and sync is done only to initialize the keyspace. When synchronization is extended to the whole method, the system finds itself in a deadlock. This means that some keyspace is tried to be opened during initiazation. Currently it works fine because the keyspace which is not initialized yet is never tried to be opened asynchronously while initializing some other keyspace in a different thread. Hence the conclusion about fragility of the current solution.



--
This message was sent by Atlassian Jira
(v8.20.1#820001)

---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cassandra.apache.org
For additional commands, e-mail: commits-help@cassandra.apache.org