You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Dmitriy Setrakyan (JIRA)" <ji...@apache.org> on 2015/08/01 02:35:04 UTC

[jira] [Commented] (IGNITE-1159) Redundant MVCC queue iteration may be removed

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

Dmitriy Setrakyan commented on IGNITE-1159:
-------------------------------------------

Reviewed: 
* I believe that method {{GridCacheMvccManager.unlink()}} is not used and can be removed. 

Otherwise looks good.

> Redundant MVCC queue iteration may be removed
> ---------------------------------------------
>
>                 Key: IGNITE-1159
>                 URL: https://issues.apache.org/jira/browse/IGNITE-1159
>             Project: Ignite
>          Issue Type: Bug
>          Components: cache
>    Affects Versions: sprint-7
>            Reporter: Alexey Goncharuk
>            Assignee: Dmitriy Setrakyan
>             Fix For: sprint-8
>
>         Attachments: master_ignite-1159.patch
>
>
> When MVCC lock candidates are added for multiple keys, they are linked together to ensure proper lock acquisition order. The linkage is done in GridCacheMvccManager#addNext()
> The manager contains a thread-local queue of previously added candidates which is reset after each message. When a candidate is added, addNext() iterates over the queue and unlinks used candidates.
> The drawback of this code is that on large batches of size N (say, a batch of 100 values) the code will execute N^2 operations which dramatically reduces performance of bulk transactions.
> It looks like that this code is unnecessary because:
> 1) Candidates cannot become used while lock request being processed.
> 2) There is no need to unlink as the candidates will be GCed after locks are released.



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