You are viewing a plain text version of this content. The canonical link for it is here.
Posted to oak-issues@jackrabbit.apache.org by "Nitin Gupta (Jira)" <ji...@apache.org> on 2022/12/21 03:40:00 UTC

[jira] [Closed] (OAK-9966) Internal code calls Node.isCheckedOut and VersionManager.isCheckedOut

     [ https://issues.apache.org/jira/browse/OAK-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Nitin Gupta closed OAK-9966.
----------------------------

> Internal code calls Node.isCheckedOut and VersionManager.isCheckedOut
> ---------------------------------------------------------------------
>
>                 Key: OAK-9966
>                 URL: https://issues.apache.org/jira/browse/OAK-9966
>             Project: Jackrabbit Oak
>          Issue Type: Improvement
>          Components: core, jcr
>            Reporter: Angela Schreiber
>            Assignee: Angela Schreiber
>            Priority: Major
>              Labels: performance
>             Fix For: 1.46.0
>
>
> while investigating a report about performance issues in Oak i came across stacktraces reporting excessive permission evaluation during {{ReadOnlyVersionManager.isCheckedOut(Tree)}}
> there are a couple of things that struck me and which might be valuable improvements:
> h2. Internal Calls to VersionManager.isCheckedOut(String)
> - JCR call {{NodeImpl.isCheckedOut}} calls JCR API {{VersionManager.isCheckedOut(String path)}}, i.e. forcing the {{Tree}} object to be accessed again, when it was already present with the NodeImpl
> - JCR call {{NodeImpl.canAddMixin}} calls JCR API {{VersionManager.isCheckedOut(String path)}}, i.e. forcing the {{Tree}} object to be accessed again, when it was already present with the NodeImpl
> - {{ImporterImpl}} constructor calls JCR API {{VersionManager.isCheckedOut(String path)}}, i.e. forcing the {{Tree}} object to be accessed again despite the fact that it has been obtained just before
> h2. Internal Calls to Node.isCheckedOut() which calls VersionManager.isCheckedOut(String)
> - JCR call {{NodeImpl.setPrimaryType}} calls JCR API {{Node.isCheckedOut}} 
> - JCR call {{NodeImpl.addMixin}} calls JCR API {{Node.isCheckedOut}} 
> - JCR call {{NodeImpl.removeMixin}} calls JCR API {{Node.isCheckedOut}} 
> - Jackrabbit API call {{NodeImpl.setMixins}} calls JCR API {{Node.isCheckedOut}} 
> - JCR call {{QueryImpl.storeAsNode}} calls JCR API {{Node.isCheckedOut}} 
> - JCR call {{SessionImpl.hasCapability}} calls JCR API {{Node.isCheckedOut}} after having retrieved the node.- JCR call {{PropertyImpl.remove()}} calls JCR API {{Node.isCheckedOut}} on parent node
> - internal call {{NodeImpl.internalSetProperty(String,Value,boolean)}} calls JCR API {{Node.isCheckedOut}} 
> - internal call {{NodeImpl.internalSetProperty(String,Value[],boolean)}} calls JCR API {{Node.isCheckedOut}} 
> - internal call {{NodeImpl.internalRemoveProperty}}  calls JCR API {{Node.isCheckedOut}} 
> - internal call {{PropertyImpl.internalSetValue(Value)}} calls JCR API {{Node.isCheckedOut}}  on parent node
> - - internal call {{PropertyImpl.internalSetValue(Value[])}} calls JCR API {{Node.isCheckedOut}}  on parent node
> h2. ReadOnlyVersionManager.isCheckedOut(Tree)
> - The implementation of {{ReadOnlyVersionManager.isCheckedOut(Tree)}} verifies that the passed tree exists despite the fact that most callers of this method have already verified that the tree exists (e.g. the node was retrieved through JCR API).
> - The implementation will recursively walk up the hierarchy to check if any of the parents is check-in (again verifying the existence and accessibility of the parent, which in this case is likely not relevant as it is an internal call that doesn't leak any information if the parent tree is not readable to the editing session)
> [~jhoh], [~mreutegg] wdyt?



--
This message was sent by Atlassian Jira
(v8.20.10#820010)