[
https://issues.apache.org/jira/browse/IGNITE-24360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-24360:
-------------------------------------
Description:
h3. Motivation
Within colocation track we should reasonably move table-not-specific requests
and commands processing from PartitionReplicaListener and PartitionListener to
ZonePartitionReplicaListener and ZonePartitionRaftListener.
ReplicaSafeTimeSyncRequest is one of such requests to be moved. In this
particular case TxStateCommitPartitionRequest is expected to be moved.
h3. Definition of Done
* It's possible to resolve transaction state from the zone's commit partition.
h3. Implementation Notes
* As for TxMessageSender#resolveTxStateFromCommitPartition we will have zoneId
instead of tableId because it's retrieved from WI.commitPartitionId. See
PartitionReplicaListener#resolveWriteIntentReadability for more details.
However we will need to use proper request to message conversion. Please pay
attention to toTablePartitionIdMessage.
{code:java}
.groupId(toTablePartitionIdMessage(REPLICA_MESSAGES_FACTORY, commitGrpId))
{code}
* Check all usages of TxMessageSender#resolveTxStateFromCommitPartition in
order not to skip places where tableId is used. I assume that we may have tests
where tableId is explicitly propagated to the method.
* Copy PartitionReplicaListener#processTxStateCommitPartitionRequest along
with corresponding trigger to ZonePartitionReplicaListener.
* Hide original PartitionReplicaListener#processTxStateCommitPartitionRequest
under colocation feature flag.
* I don't expect any tests here, since it given ticket is a part of WI
Resolution flow that should be checked when fully moved to zones.
was:
h3. Motivation
Within colocation track we should reasonably move table-not-specific requests
and commands processing from PartitionReplicaListener and PartitionListener to
ZonePartitionReplicaListener and ZonePartitionRaftListener.
ReplicaSafeTimeSyncRequest is one of such requests to be moved. In this
particular case TxStateCommitPartitionRequest is expected to be moved.
h3. Definition of Done
* It's possible to resolve transaction state from the zone's commit partition.
h3. Implementation Notes
* Add clockService to ZonePartitionReplicaListener.
* Copy PartitionReplicaListener#processReplicaSafeTimeSyncRequest along with
corresponding trigger to ZonePartitionReplicaListener.
* Hide originalPartitionReplicaListener#processReplicaSafeTimeSyncRequest
under colocation feature flag.
* Copy PartitionListener#handleSafeTimeSyncCommand to
ZonePartitionRaftListener. I guess that it's the most tricky part here, because
we will need to advance safeTime and index consistently in _all_ data storages
(meaning for all tables) of a zone.
** I believe that we may change advanceLastAppliedIndexConsistently from
private to public __ and call it for all tableProcessors that we have in
ZonePartitionReplicaListener for specific zone.
** Besides that we may move 'if (commandIndex <= storage.lastAppliedIndex())'
from handleSafeTimeSyncCommand to advanceLastAppliedIndexConsistently.
* Add corresponding test.
> Implement TxStateCommitPartitionRequest processing for zone replica
> -------------------------------------------------------------------
>
> Key: IGNITE-24360
> URL: https://issues.apache.org/jira/browse/IGNITE-24360
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> Within colocation track we should reasonably move table-not-specific requests
> and commands processing from PartitionReplicaListener and PartitionListener
> to ZonePartitionReplicaListener and ZonePartitionRaftListener.
> ReplicaSafeTimeSyncRequest is one of such requests to be moved. In this
> particular case TxStateCommitPartitionRequest is expected to be moved.
> h3. Definition of Done
> * It's possible to resolve transaction state from the zone's commit
> partition.
> h3. Implementation Notes
> * As for TxMessageSender#resolveTxStateFromCommitPartition we will have
> zoneId instead of tableId because it's retrieved from WI.commitPartitionId.
> See PartitionReplicaListener#resolveWriteIntentReadability for more details.
> However we will need to use proper request to message conversion. Please pay
> attention to toTablePartitionIdMessage.
> {code:java}
> .groupId(toTablePartitionIdMessage(REPLICA_MESSAGES_FACTORY, commitGrpId))
> {code}
> * Check all usages of TxMessageSender#resolveTxStateFromCommitPartition in
> order not to skip places where tableId is used. I assume that we may have
> tests where tableId is explicitly propagated to the method.
> * Copy PartitionReplicaListener#processTxStateCommitPartitionRequest along
> with corresponding trigger to ZonePartitionReplicaListener.
> * Hide original
> PartitionReplicaListener#processTxStateCommitPartitionRequest under
> colocation feature flag.
> * I don't expect any tests here, since it given ticket is a part of WI
> Resolution flow that should be checked when fully moved to zones.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
