[
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.
* resolveTxStateFromCommitPartition may trigger
{code:java}
triggerTxRecoveryOnTxStateResolutionIfNeeded{code}
thus <alapin TBD> there is a dependent ticket.
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
* 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.
> 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.
> * resolveTxStateFromCommitPartition may trigger
> {code:java}
> triggerTxRecoveryOnTxStateResolutionIfNeeded{code}
> thus <alapin TBD> there is a dependent ticket.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
