[
https://issues.apache.org/jira/browse/OAK-9966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Angela Schreiber resolved OAK-9966.
-----------------------------------
Fix Version/s: 1.46.0
Resolution: Fixed
> 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)
