[ 
https://issues.apache.org/jira/browse/IGNITE-7823?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Pavel Pereslegin updated IGNITE-7823:
-------------------------------------
    Comment: was deleted

(was: Implementation details.
* DataStructuresProcessor#compatibleCache creates separate cache for each new 
non-collocated version of IgniteSet (method IgniteSet#close destroys this 
cache).
 * A new implementation of IgniteSet called IgniteCacheSetImpl was introduced 
(also a separate proxy IgniteCacheSetProxy was created), duplicate code 
(GridCacheSetImpl and GridCacheSetProxy) should be removed in next major 
release.
 * Header is not used by non-collocated version of IgniteSet. 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 of non-collocated 
version on each invocation.)

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

Reply via email to