[jira] [Updated] (IGNITE-7807) SQL TX: Store lock info inside tuples
[
https://issues.apache.org/jira/browse/IGNITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7807:
Component/s: mvcc
> 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: mvcc, sql
>Reporter: Vladimir Ozerov
>Assignee: Igor Seliverstov
>Priority: Major
> Fix For: 2.7
>
>
> 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)
[jira] [Updated] (IGNITE-7807) SQL TX: Store lock info inside tuples
[
https://issues.apache.org/jira/browse/IGNITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dmitriy Pavlov updated IGNITE-7807:
---
Fix Version/s: (was: 2.6)
2.7
> 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
> Fix For: 2.7
>
>
> 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)
[jira] [Updated] (IGNITE-7807) SQL TX: Store lock info inside tuples
[
https://issues.apache.org/jira/browse/IGNITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Igor Seliverstov updated IGNITE-7807:
-
Fix Version/s: (was: 2.5)
2.6
> 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
> Fix For: 2.6
>
>
> 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)
[jira] [Updated] (IGNITE-7807) SQL TX: Store lock info inside tuples
[
https://issues.apache.org/jira/browse/IGNITE-7807?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vladimir Ozerov updated IGNITE-7807:
Fix Version/s: 2.5
> 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
> Fix For: 2.5
>
>
> 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)
