[ 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)