[
https://issues.apache.org/jira/browse/IGNITE-22214?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Alexander Lapin updated IGNITE-22214:
-------------------------------------
Description:
h3. Motivation
General context is available in the IGNITE-21881. Within given ticket it's
required to persist and restore idempotent command cache in order to return
original command result after raft node restart.
h3. Definition of Done
* Original command result is returned after raft node restart.
h3. Implementation Notes
Seems that the easiest way to implement the desired solution and get all
snapshot consistency aspects out of the box is to store each idempotent cache
entry in dedicated MS key where key itself will be
<idempotentCommandCachePrefix>commandId with the original command result as
value. I don't think that we need to persist command startTime, we may
recalculate it on cache initialisation - it's all matter of optimisation and
not correctness. Meaning that it's safe to have value in cache a little bit
longer than it's actually required.
was:
h3. Motivation
General context is available in the
[IGNITE-21881|https://issues.apache.org/jira/browse/IGNITE-21881]. Within given
ticket it's requ
> Meta storage idempotent invokes: persist and recovery idempotent command cache
> ------------------------------------------------------------------------------
>
> Key: IGNITE-22214
> URL: https://issues.apache.org/jira/browse/IGNITE-22214
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexander Lapin
> Priority: Major
> Labels: ignite-3
>
> h3. Motivation
> General context is available in the IGNITE-21881. Within given ticket it's
> required to persist and restore idempotent command cache in order to return
> original command result after raft node restart.
> h3. Definition of Done
> * Original command result is returned after raft node restart.
> h3. Implementation Notes
> Seems that the easiest way to implement the desired solution and get all
> snapshot consistency aspects out of the box is to store each idempotent cache
> entry in dedicated MS key where key itself will be
> <idempotentCommandCachePrefix>commandId with the original command result as
> value. I don't think that we need to persist command startTime, we may
> recalculate it on cache initialisation - it's all matter of optimisation and
> not correctness. Meaning that it's safe to have value in cache a little bit
> longer than it's actually required.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
