[
https://issues.apache.org/jira/browse/IGNITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16400573#comment-16400573
]
Vladimir Ozerov commented on IGNITE-7807:
-----------------------------------------
[~gvvinblade], my comments:
1) IgniteCacheDatabaseSharedManager.initializeForCache - dead code
2) IgniteCacheOffheapManager.mvccMaxVersion - dead code
3) IgniteCacheOffheapManagerImpl - TODOs
4) MvccProcessor.waitList - can't we use CHM here? Appears to be another
scalability bottlneck in case of massive conflicting updates.
> SQL TX: Store lock info inside tuples
> -------------------------------------
>
> Key: IGNITE-7807
> URL: https://issues.apache.org/jira/browse/IGNITE-7807
> Project: Ignite
> Issue Type: Task
> Components: sql
> Reporter: Vladimir Ozerov
> Assignee: Igor Seliverstov
> Priority: Major
>
> We need to store lock info inside tuples. Otherwise, touching a lot of
> entries would lead to OOME. Also we should rework our locking logic - instead
> of trying to enlist ourselves in every entry, we should stop on the very
> first locked entry and wait for it's release.
> Suggested fix:
> 1) Check for {{lock_id}} field of an entry
> 2) If it is empty, CAS own XID
> 3) If it is not empty, check fo TX LOG to see if transaction is still active;
> if not - CAS itself
> 4) If failed to install own version - stop locking and wait for release
> 5) When transaction commits, no locks are released explicilty. Instead, it is
> responsibility of the next locker to check TX LOG and undesrantnad whether
> entry could be locked or not
> 6) When lock is acquired, create new version of an entry with lock info
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
