[ 
https://issues.apache.org/jira/browse/CASSANDRA-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

C. Scott Andreas updated CASSANDRA-10283:
-----------------------------------------
    Component/s: Local Write-Read Paths

> Create central class that represents node's local data store
> ------------------------------------------------------------
>
>                 Key: CASSANDRA-10283
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-10283
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core, Local Write-Read Paths
>            Reporter: Yuki Morishita
>            Priority: Minor
>              Labels: refactoring
>             Fix For: 4.x
>
>
> This is related to CASSANDRA-7837 which aims to take down static 
> initializations and singletons. Instead of doing it all at once, we can / 
> should conquer by dividing internal to several part as discussed in that 
> ticket. I just throw in my thought to discuss further.
> The node local data store (commitlog, memtable, SSTable etc) is at the core 
> of Cassandra, and I think it is good to start from here.
> The central class for local data store class (I refer it as 
> {{CassandraDataStore}} from here) manages the following:
> * CommitLog
> * CacheService
> * IndexSummaryManager
> * Keyspace / ColumnFamilyStore
> * CompactionManager
> * Schema / SchemaKeyspace
> * MemtablePool
> and possibly others, basically those that don't use {{MessagingService}}. 
> These classes won't have static initialization/accessors and singleton, as 
> {{CassandraDataStore}} initializes and wires them as necessary. We also can 
> take access to {{DatabaseDescriptor}} away from these classes as 
> {{CassandraDataStore}} does initialization (but this can be done separately).
> Of course, even after this, we still need to have one singleton instance that 
> is {{CassandraDataStore}} itself to be accessed from other modules, but it 
> will eventually be gone as we take down other part of singletons.
> Benefits to do this includes:
> * More explicit startup and cleanup procedure. It is hard to tell what is 
> initialized when right now, and sometimes it creates unpredected result.
> * Simpler unit test setup. We don't need to bootstrap messaging or gossip to 
> test local only functionality.
> Even the scope of the change is limitted compare to CASSANDRA-7837, this 
> needs a lot of effort still and change to the code is still huge. But I 
> believe this is worth the shot, and I appreciate any feedbacks regarding 
> feasibility.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Reply via email to