You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladimir Ozerov (JIRA)" <ji...@apache.org> on 2016/03/24 12:36:25 UTC

[jira] [Commented] (IGNITE-2885) Avoid usage of GridDhtLocalPartition.rmvQueue for Transactional caches

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

Vladimir Ozerov commented on IGNITE-2885:
-----------------------------------------

I would like to mention that this remove queue is also important for our "conflcits" API which can be employed by plugins. When entry is removed from cache, we still store it's version in queue. As a result, conflict resolver is able to use this version to discard conflicting or out-of-ordered updates.

I do not think we should remove this queue right away.

> Avoid usage of GridDhtLocalPartition.rmvQueue for Transactional caches
> ----------------------------------------------------------------------
>
>                 Key: IGNITE-2885
>                 URL: https://issues.apache.org/jira/browse/IGNITE-2885
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: 1.5.0.final
>            Reporter: Denis Magda
>
> There is a property that controls maximum remove queue
> history for atomic caches (IgniteSystemProperties.IGNITE_ATOMIC_CACHE_DELETE_HISTORY_SIZE).
> The strange thing is that this property is also used for transactional
> caches as well allocating {{GridDhtLocalPartition.rmvQueue}}
> regardless of a cache atomicity type which looks confusing.
> In case of transaction caches the queue is used to resolve rebalancing and concurrent puts races. We can try remove it once a partition gets loaded.
> Seems that we can't get rid off the queue completely because to support this we need to switch to fair thread-per-partition design.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)