[jira] [Assigned] (IGNITE-18632) Barrier for locks after cleanup started

["Vladislav Pyatkov (Jira)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/IGNITE-18632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Vladislav Pyatkov reassigned IGNITE-18632:
------------------------------------------

    Assignee: Vladislav Pyatkov

> Barrier for locks after cleanup started
> ---------------------------------------
>
>                 Key: IGNITE-18632
>                 URL: https://issues.apache.org/jira/browse/IGNITE-18632
>             Project: Ignite
>          Issue Type: Bug
>            Reporter: Denis Chudov
>            Assignee: Vladislav Pyatkov
>            Priority: Major
>              Labels: ignite-3
>
> *Motivation*
> Transaction locks are acquired on primary replicas and must be released on tx cleanup (on processing of cleanup request to primary replica). This means, no lock for certain transaction can be acquired after the processing of cleanup request has begun. However, messaging protocol doesn't provide any linearization guarantees, so we should have this synchronization implemented in replica listener. For current implementation the following is possible:
> - put request and cleanup request for the same primary replica and for the same transaction are reordered by messaging;
> - cleanup starts and releases locks for corresponding tx;
> - processing of put request starts and acquires locks that will never be released.
> *Definition of done:*
> After cleanup for certain transaction on certain primary replilca has started, it's impossible to acquire lock for this transaction on this primary replica.
> *Implementation notes:*
> There is synchronization between adding write intents to storage on primary replica and cleanup start (see IGNITE-18527 ). The implementation should take into account that cleanup can't start while write intentis being written into a storage, and cleanup command should not be fired before update command. However, this ticket is not only about update requests/commands, as read requests also acquire locks on primary replica, and they also need to be synchronized with cleanup.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)