[
https://issues.apache.org/jira/browse/IGNITE-11739?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sergey Chugunov updated IGNITE-11739:
-------------------------------------
Issue Type: Improvement (was: Task)
> Refactoring of cache lifecycle and cache configuration management code
> ----------------------------------------------------------------------
>
> Key: IGNITE-11739
> URL: https://issues.apache.org/jira/browse/IGNITE-11739
> Project: Ignite
> Issue Type: Improvement
> Components: cache
> Reporter: Sergey Chugunov
> Priority: Major
>
> h2. Problem
> Currently code responsible for cache lifecycle and configuration management
> is spread across different entities (e.g. GridCacheProcessor,
> GridCacheAffinityManager, ClusterCachesInfo and so on).
> Cache configuration data is duplicated multiple times and presented in
> different forms from StoredCacheData to CacheGroupDescriptor to
> DynamicCacheDescriptor to ClusterCachesInfo.
> Altogether there is no entity nor abstraction which contains most of the
> logic of managing cache state and config and provides a clean API for this
> purpose.
> All this makes it hard to maintain the code, fix bugs and make improvements
> so need for refactoring and benefits from it are obvious.
> h2. Approaches
> # Build state machine manipulating immutable state objects to reflect
> transitions between states.
> # Concentrate all cache-related info into a new (abstraction like cache
> container) or existing (e.g. cache context) mutable entity and manipulate
> that entity to reflect evolution of cache.
> # Some mix of these two approaches.
> There are already plenty of entities like CacheInfo or CacheDescriptor with
> names suggesting they contain information about cache.
> The problem though is that each of these entities manages only some part of
> information.
> Regardless of which approach is used clear and well documented API should be
> provided for managing lifecycle and configuration.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
