[jira] [Commented] (IGNITE-7807) SQL TX: Store lock info inside tuples

["Vladimir Ozerov (JIRA)" <ji...@apache.org>]

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