JCR API Usage Configuration

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.

Implementation notices

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".

Copyright ©. All rights reserved. eXo Platform SAS
blog comments powered byDisqus