[
https://issues.apache.org/jira/browse/SLING-10011?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17260564#comment-17260564
]
Miroslav Smiljanic commented on SLING-10011:
--------------------------------------------
[~angela] suggested to add [test
cases|https://svn.apache.org/viewvc?view=revision&revision=1885241] when parent
node is not visible for the current session.
When user session does not have access permission for the parent node,
exception is being thrown and contributes to the operation execution time.
Still, in all cases when retrieving the parent node, Node API performs better
than Session API.
Test run with cache enabled.
{noformat}
> java -jar target/oak-benchmarks-*-SNAPSHOT.jar benchmark --runAsAdmin false
> GetParentVisibleNodeAPI GetParentVisibleSessionAPI GetParentNotVisibleNodeAPI
> GetParentNotVisibleSessionAPI Oak-Segment-Tar
Apache Jackrabbit Oak 1.37-SNAPSHOT
# GetParentVisibleNodeAPI C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 2 2 2 3 5
25285 2
# GetParentVisibleSessionAPI C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 26 27 28 30 39
2121 28
# GetParentNotVisibleNodeAPI C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 15 16 17 18 23
3515 17
# GetParentNotVisibleSession C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 35 36 38 40 52
1574 38
{noformat}
Test run with cache disabled.
{noformat}
> java -jar target/oak-benchmarks-*-SNAPSHOT.jar benchmark --runAsAdmin false
> --cache 0 GetParentVisibleNodeAPI GetParentVisibleSessionAPI
> GetParentNotVisibleNodeAPI GetParentNotVisibleSessionAPI Oak-Segment-Tar
Apache Jackrabbit Oak 1.37-SNAPSHOT
# GetParentVisibleNodeAPI C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 8 8 9 11 17
6527 9
# GetParentVisibleSessionAPI C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 2302 2306 2317 2339 2349
26 2320
# GetParentNotVisibleNodeAPI C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 19 20 21 24 30
2761 22
# GetParentNotVisibleSession C min 10% 50% 90% max
N mean
Oak-Segment-Tar 1 2349 2362 2372 2395 2409
26 2374
{noformat}
> 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)
