[
https://issues.apache.org/jira/browse/SLING-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17252923#comment-17252923
]
Miroslav Smiljanic commented on SLING-10011:
--------------------------------------------
There is functionally, nothing wrong with the current approach of accessing
nodes (even the parent node) using absolute path, with session.getItem(path).
It is only that, with that approach, chosen by the client application (Sling in
this case), we can not benefit out of node bundling, when trying to reach
parent node.
There is also no issue in Oak, and both options are legal
# session.getItem(path) – currently used
# childItem.getParent() - proposed change
There is no big difference in performance of the application powered by Sling,
if JCR repository as a storage uses locally attached SSD disc.
But if repository data is persisted on remote cloud storage, goal is to
decrease number of network roundtrips during request processing, since they can
increase overall response time.
First option does not benefit from node bundling/aggregation, and to decrease
number of network roundtrips, node cache has to be maintained. Performance of
the cache (invalidation rate) depends on the repository size and on the number
of concurrent requests accessing different parts of the repository. Also,
increasing cache size is impacting cost to run the application.
The second option can benefit form node bundling/aggregation, where for a given
node type the whole subtree is loaded form the remote storage, and form that
moment the whole subtree is traversed in memory, but only if node/item JCR API
is used. With this approach application still can benefit out of internal
caches used, but caching strategy does not need to be as aggressive, and it is
easier to predict baseline performance since number of network roundtrips to
the remote storage is predictable.
It is up to the client application to be aware about those differences and make
appropriate choice.
So all options are valid form the expected functionality point of view, but not
the cost of running the application backed by remote storage, when we want to
guarantee similar baseline performance.
I hope this helps to clarify improvement request.
> Use javax.jcr.Item.getParent() when resolving parent JCR node in
> JcrResourceProvider#getParent
> ----------------------------------------------------------------------------------------------
>
> Key: SLING-10011
> URL: https://issues.apache.org/jira/browse/SLING-10011
> Project: Sling
> Issue Type: Improvement
> Components: JCR
> Affects Versions: JCR Resource 3.0.22
> Reporter: Miroslav Smiljanic
> Priority: Minor
> Time Spent: 20m
> Remaining Estimate: 0h
>
> Currently
> [JcrResourceProvider.getParent|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/org.apache.sling.jcr.resource-3.0.22/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProvider.java#L361]
> is using JcrItemResourceFactory.getItemOrNull(String path), which eventually
> is using JCR session to retrieve parent node using absolute path.
> I propose using javax.jcr.Item.getParent() instead.
> Reasoning wold be to utilise potential improvements in JCR implementation
> that would for a given node retrieve the whole subtree. That can be
> configured for example by using particular node type or node path.
> {noformat}
> root
> |
> a
> / \
> b c
> {noformat}
> If node 'a' in picture above, is matching desired configuration, then code
> below would return the whole subtree.
> {code:java}
> Node a = jcrSession.getNode("a");
> {code}
> That further means retrieved subtree can be traversed in memory, without the
> need to communicate with the JCR repository storage.
> (!)That is particularly important when remote (cloud) storage is used for
> repository in JCR implementation, and tree traversal can be done without
> doing additional network roundtrips.
> {code:java}
> //JCR tree traversal happens in memory
> Node b = a.getNode("b");
> Node c = a.getNode("c");
> {code}
> Also going from child to parent, is resolved in memory as well (proposal
> relates to this fact)
> {code:java}
> //JCR tree traversal happens in memory
> assert b.getParent() == c.getParent();
> {code}
> Jackrabbit Oak, for document node store is supporting node bundling for
> configured node type
> [http://jackrabbit.apache.org/oak/docs/nodestore/document/node-bundling.html]
> Currently I am also doing some experiments to support node
> bundling/aggregation for arbitrary node store
> ([NodeDelegateFullyLoaded|https://github.com/smiroslav/jackrabbit-oak/blob/ppnextgen_newstore/oak-jcr/src/main/java/org/apache/jackrabbit/oak/jcr/delegate/NodeDelegateFullyLoaded.java],
>
> [FullyLoadedTree|https://github.com/smiroslav/jackrabbit-oak/blob/ppnextgen_newstore/oak-core/src/main/java/org/apache/jackrabbit/oak/core/FullyLoadedTree.java]).
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
