[ https://issues.apache.org/jira/browse/IGNITE-13220?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Alexey Goncharuk updated IGNITE-13220: -------------------------------------- Description: 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. was: 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. > 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 > Priority: Major > > 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 (v8.3.4#803005)