[
https://issues.apache.org/jira/browse/IGNITE-1159?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14641119#comment-14641119
]
Dmitriy Setrakyan commented on IGNITE-1159:
-------------------------------------------
I agree. The code to check for released locks every time a new lock is acquired
is unnecessary. It was done by me a few years back, and I am sure I had a
reason for it back then, but at this point I can't think of it. Let's trying
removing it and see if CI fails.
> 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: Alexey Goncharuk
> Fix For: sprint-8
>
>
> 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)
