[jira] [Updated] (IGNITE-13220) Cleanup IgniteCacheOffheapManager interface

["Alexey Goncharuk (Jira)" <ji...@apache.org>]

     [ 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)