[
https://issues.apache.org/jira/browse/IGNITE-18527?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Denis Chudov reassigned IGNITE-18527:
-------------------------------------
Assignee: Denis Chudov
> Inline writeIntents into data storage on primary replica side
> -------------------------------------------------------------
>
> Key: IGNITE-18527
> URL: https://issues.apache.org/jira/browse/IGNITE-18527
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Assignee: Denis Chudov
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> In order to have an ability for primary replica not to be collocated with
> raft leader it's required to populate primary replica's data storage and
> indices with corresponding updates directly, bypassing the replication
> protocol. Basically speaking it's required to perform handleUpdateCommand,
> handleUpdateAllCommand logic from within handling replica request and not
> raft command itself. It's required in order to perform straight non-raft data
> reads from primary replica, meaning that if leader ins't collocated with
> primary replica it's possible that write will be considered as finished
> without populating primary replica's state machine and thus dataStorage with
> corresponding write command.
> h3. Definition of Done
> * It's possible to consistently read data from primary replica event if it's
> not collocated with the leader.
> * There are no conflicts during re-applying a writeIntent within in-raft
> communication on top of the same already existing one that was created during
> primary replica caching process.
> * Given write intents are cleaned up on tx rollback.
> h3. Implementation Notes
> It worth to mention that :
> * Re-applying a write intents may be tricky.
> * And besides that we must ensure that adding writeIntent initiated by
> _replication_ message is linearized with tx cleanup on rollback.
> the rest seems to be quite simple.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
