You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@ignite.apache.org by "Vladislav Pyatkov (Jira)" <ji...@apache.org> on 2023/01/24 07:52:00 UTC

[jira] [Commented] (IGNITE-18527) Inline writeIntents into data storage on primary replica side

    [ https://issues.apache.org/jira/browse/IGNITE-18527?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17680125#comment-17680125 ] 

Vladislav Pyatkov commented on IGNITE-18527:
--------------------------------------------

LGTM

> 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
>          Time Spent: 20m
>  Remaining Estimate: 0h
>
> 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)