[
https://issues.apache.org/jira/browse/IGNITE-12802?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17072513#comment-17072513
]
Stanilovsky Evgeny commented on IGNITE-12802:
---------------------------------------------
[~agoncharuk] seems i complete with refactoring, may be it would be enough for
beginning :?) Still i have several questions:
1. why do we need {noformat}CheckpointProgress{noformat} suppose not more than
one implementation need to be here.
2. inner Checkpointer class and all stuff around it.
but looks like this work for another tickets, what do you think ?
> Move checkpoint state fields to CheckpointProgress
> --------------------------------------------------
>
> Key: IGNITE-12802
> URL: https://issues.apache.org/jira/browse/IGNITE-12802
> Project: Ignite
> Issue Type: Improvement
> Reporter: Alexey Goncharuk
> Assignee: Stanilovsky Evgeny
> Priority: Major
> Time Spent: 0.5h
> Remaining Estimate: 0h
>
> This is a review follow-up for IGNITE-7792. I've noticed that quite a few
> fields in {{GridCacheDatabaseSharedManager}} are related to the state of
> current checkpoint:
> {code}
> writtenPagesCntr
> syncedPagesCntr
> evictedPagesCntr
> currCheckpointPagesCnt
> {code}
> After checkpoint is completed, these fields are reset. On the other hand, we
> have a separate class to track the state of current checkpoint:
> {{CheckpointProgressImpl}}. I believe it makes sense to move these fields to
> the separate class. Perhaps, it also makes sense to make this class a
> top-level class.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
