[jira] [Updated] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15057: --- Epic Link: IGNITE-15081 > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 50m > Remaining Estimate: 0h > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > More specifically, suppose a transaction Ti tries to wait for Tj => lock > order is [Tj, Ti]. If Ti has lower priority than Tj (i.e., Ti is younger than > Tj), then Ti is permitted to wait => [Tj=10, Ti=20]. Otherwise [Tj=20, Ti=10] > => Ti is aborted. > Aborted transactions must be restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.20.1#820001)
[jira] [Updated] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15057: --- Description: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. More specifically, suppose a transaction Ti tries to wait for Tj => lock order is [Tj, Ti]. If Ti has lower priority than Tj (i.e., Ti is younger than Tj), then Ti is permitted to wait => [Tj=10, Ti=20]. Otherwise [Tj=20, Ti=10] => Ti is aborted. Aborted transactions must be restarted preserving it's timestamp. was: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. Otherwise, newer transactions must be restarted preserving it's timestamp. > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > More specifically, suppose a transaction Ti tries to wait for Tj => lock > order is [Tj, Ti]. If Ti has lower priority than Tj (i.e., Ti is younger than > Tj), then Ti is permitted to wait => [Tj=10, Ti=20]. Otherwise [Tj=20, Ti=10] > => Ti is aborted. > Aborted transactions must be restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15057: --- Description: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. Otherwise, newer transactions must be restarted preserving it's timestamp. was: We assume two phase locking concurrency control in the first version of tx protocol in Ignite 3. We need a LockManager implementing this functionality. If a shared/exclusive lock is acquired in incompatible mode, only "newest" operations are allowed to wait for "oldest", according to ordering based on globally comparable timestamp. Otherwise, newer transactions are restarted preserving it's timestamp. > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > Time Spent: 10m > Remaining Estimate: 0h > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > Otherwise, newer transactions must be restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15057: --- Ignite Flags: (was: Release Notes Required) > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > Otherwise, newer transactions are restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
[jira] [Updated] (IGNITE-15057) Implement LockManager with deadlock prevention based on operation ordering
[ https://issues.apache.org/jira/browse/IGNITE-15057?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Alexey Scherbakov updated IGNITE-15057: --- Ignite Flags: Release Notes Required (was: Docs Required,Release Notes Required) > Implement LockManager with deadlock prevention based on operation ordering > -- > > Key: IGNITE-15057 > URL: https://issues.apache.org/jira/browse/IGNITE-15057 > Project: Ignite > Issue Type: Task >Affects Versions: 3.0.0-alpha2 >Reporter: Alexey Scherbakov >Assignee: Alexey Scherbakov >Priority: Major > Labels: iep-61, ignite-3 > Fix For: 3.0.0-alpha3 > > > We assume two phase locking concurrency control in the first version of tx > protocol in Ignite 3. > We need a LockManager implementing this functionality. > If a shared/exclusive lock is acquired in incompatible mode, only "newest" > operations are allowed to wait for "oldest", according to ordering based on > globally comparable timestamp. > Otherwise, newer transactions are restarted preserving it's timestamp. -- This message was sent by Atlassian Jira (v8.3.4#803005)
