[
https://issues.apache.org/jira/browse/IGNITE-18632?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17688518#comment-17688518
]
Denis Chudov commented on IGNITE-18632:
---------------------------------------
LGTM.
> 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
> Time Spent: 40m
> Remaining Estimate: 0h
>
> *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)
