eXo JCR implementation offers a new extended feature beyond the JCR specification. Sometimes one JCR Node has hundreds or even thousands of child nodes. This situation is highly not recommended for content repository data storage, but sometimes it occurs. They can be iterated in a "lazy" manner by giving improvement in terms of performance and RAM usage.
Current "lazy" child nodes iterator supports caching, when pages
are cached atomically in safe and optimized way. Cache is always kept in
consistent state using invalidation if child list changed. Take into
account the following difference in getNodes and getNodesLazily.
Specification which defines the getNode method reads the whole list of nodes,
so child items added after invocation will never be in results.
GetNodesLazily does not acquire full list of nodes, so child items added
after iterator creation can be found in result. So getNodesLazily can
represent some types of "real-time" results. But it is highly dependent on
numerous conditions and should not be used as a feature, it is more likely an
implementation specific issue typical for "lazy-pattern".