[
https://issues.apache.org/jira/browse/JCR-1638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12602574#action_12602574
]
angela commented on JCR-1638:
-----------------------------
the problem is caused by the following behaviour of jcr2spi:
- whenever a ChildNodeEntries object is built, it loads the child-infos from
the spi layer
this is obviously not optimal and we discussed it at least once in the past.
in order to fix that we would need to
- keep a flag with ChildNodeEntries implementation indicating whether the
complete list has been
read or not.
- by default don't load the child info entries upon entries construction
- populate the ChildNodeEntries lazily
- load all infos only upon calls to Node.getNodes or Node.getNodes(String)
- add a method to ChildNodeEntries that allows to retrieve an interator over
all entries
- adjust NodeEntryImpl avoiding that ChildNodeEntries are always built with the
'retrieveAll' flag.
> Redundant calls to RepositoryService.getChildInfos
> --------------------------------------------------
>
> Key: JCR-1638
> URL: https://issues.apache.org/jira/browse/JCR-1638
> Project: Jackrabbit
> Issue Type: Bug
> Components: jackrabbit-jcr2spi
> Reporter: Michael Dürig
>
> In some cases jcr2spi issues calls to RepositoryService.getChildInfos for
> items which haven been returned by the last call to
> RepositoryService.getItemInfos.
> This happens because WorkspaceItemStateFactory.createDeepPropertyState is
> asked to create the node states for all items returned by
> RepositoryService.getChildInfos in the order they are returned by the
> Iterator. When trying to create an item state for an item which is deeper
> down the hierarchy than another item which comes later in the iterator, a
> call to RepositoryService.getChildInfos is issued for the latter.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
