[
https://issues.apache.org/jira/browse/IGNITE-18632?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov updated IGNITE-18632:
----------------------------------
Description:
*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.
was:TBD
> 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
> 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)
