[jira] [Commented] (IGNITE-7823) Separate cache for non collocated IgniteSet.

["Pavel Pereslegin (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/IGNITE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16462769#comment-16462769 ] 

Pavel Pereslegin commented on IGNITE-7823:
------------------------------------------

Implementation details (changes affect only non-collocated version of IgniteSet).
 * DataStructuresProcessor#compatibleCache creates separate cache for each new non-collocated version of IgniteSet (method IgniteSet#close destroys this cache).
 * Header is not used by GridCacheSetImpl. Header is needed to identify keys in the shared cache, but with separate cache the GridCacheSetImpl implementation serves as an adapter for Set operations on this cache and does not require header.
 * CacheDataStructuresManager#set creates new instance GridCacheSetImpl on each invocation.
 * Flag "sharedCacheMode" in GridCacheSetImpl shows which version of Set was created (true - shared cache, false - separate cache).

> Separate cache for non collocated IgniteSet.
> --------------------------------------------
>
>                 Key: IGNITE-7823
>                 URL: https://issues.apache.org/jira/browse/IGNITE-7823
>             Project: Ignite
>          Issue Type: New Feature
>          Components: data structures
>            Reporter: Andrey Kuznetsov
>            Assignee: Pavel Pereslegin
>            Priority: Major
>             Fix For: 2.6
>
>
> Currently, single data structures cache is shared between several collection instances (IgniteQueue, IgniteSet).
> To support iterator() and size() IgniteSet maintains plain on-heap Java sets on every node (see CacheDataStructuresManager.setDataMap). These sets duplicate backing-cache entries, both primary and backup. For big non-collocated sets it's too expensive to maintain redundant onheap data copies. The simplest way to avoid copies is to use separate cache for non-collocated IgniteSet version; hence size of set is the same as size of backing cache, and also set iterator is virtually the same as backing cache iterator. 
> The difference between exising set implementation and set based on separate cache should be properly documented afterwards.



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