ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexey Goncharuk (Jira)" <j...@apache.org>
Subject [jira] [Created] (IGNITE-13220) Cleanup IgniteCacheOffheapManager interface
Date Mon, 06 Jul 2020 14:50:00 GMT
Alexey Goncharuk created IGNITE-13220:

             Summary: Cleanup IgniteCacheOffheapManager interface
                 Key: IGNITE-13220
                 URL: https://issues.apache.org/jira/browse/IGNITE-13220
             Project: Ignite
          Issue Type: Improvement
          Components: persistence
            Reporter: Alexey Goncharuk

Currently, the {{IgniteCacheOffheapManager}} interface is too verbose and there are a few
methods that leak implementation specifics:
* Easy
  *  {{void onPartitionCounterUpdated(int part, long cntr)}} is not used
  *  {{long lastUpdatedPartitionCounter(int part)}} is not used
  * {{boolean containsKey(GridCacheMapEntry entry)}} is not used
  * {{int onUndeploy(ClassLoader ldr)}} is no-op and should be removed as caches do not participate
in peer class loading
  * {{int offheapAllocatedSize}} always returns 0 and looks like it should be removed as there
are corresponding data region metrics
* Moderate
  * A number of methods in {{CacheDataStore}} are semantically equivalent to the ones {{IgniteCacheOffheapManager}}
itself: {{update}}, {{invoke}}, {{remove}}, the {{mvcc*}} methods. Looks like the duplicates
from {{IgniteCacheOffheapManager}} may be removed altogether
  * There is a number of {{iterator}} methods in the interface. Most likely, we can remove
the ones that convert cache data rows to {{CacheEntry}} objects and the ones that join multiple
partition iterators together.
  * {{void clearCache(GridCacheContext cctx, boolean readers)}} does not belong to the interface
as it can be implemented outside of the manager
* Complex
  * {{globalRemoveId}} leaks the B+Tree implementation specifics and should be removed from
the interface
  * {{rootPageForIndex}} and the corresponding destroy method leaks the page memory abstraction.
Index management should be abstracted for any type of storage.
  * There is an obvious duplication of MVCC and non-MVCC methods in the interface. For each
cache group, and therefore, for each instance of {{CacheDataStore}} only one of the sets will
be used. We should have either a single interface for both, or different interfaces, but not
two sets of methods in one interface.

This message was sent by Atlassian Jira

View raw message