[
https://issues.apache.org/jira/browse/OAK-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15303902#comment-15303902
]
Chetan Mehrotra commented on OAK-4404:
--------------------------------------
Discussed with Marcel - It would be better to directly expose the iterator from
the secondary store to address the issue there. That only leave a minor
optimization for cache case
> DocumentNodeState.childNodeEntries perform more fetches than required in some
> cases
> -----------------------------------------------------------------------------------
>
> Key: OAK-4404
> URL: https://issues.apache.org/jira/browse/OAK-4404
> Project: Jackrabbit Oak
> Issue Type: Improvement
> Components: documentmk
> Reporter: Chetan Mehrotra
> Assignee: Chetan Mehrotra
> Priority: Minor
> Attachments: OAK-4404-v1.patch
>
>
> {{DocumentNodeState}} lazily fetches the child node entries in batches of
> increasing fetchSize starting at 100. Now we have a commit where we add 200
> child nodes under /a. This list of child node entries would be cached (all
> 200 entries).
> Now if the code later tries to read all these recently added child nodes then
> DocumentNodeState would perform a fetch for initial 100. The iterator that is
> returned though is not limited to 100 and returns all 200 entries. As the
> iterator proceeds {{currentRemaining}} moves to -100 (it starts at 100 the
> expected fetchSize).
> This causes hasMore to perform one more fetch which then results in a remote
> call as its a cache miss (cache key inlcudes the base name from where the
> list should start).
> This extra call can be avoided if the {{DocumentNodeStore}} can convey the
> information that the returned iterator is complete and in such a case
> DocumentNodeState does not have to rely on its internal bookkeeping.
> This change would also be required for secondary node store based persistent
> cache to work. In those case the cache would be able to provide complete
> iterator but DocumentNodeState would not be able to make best use of this if
> it sticks to the fetch based approach
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
