[
https://issues.apache.org/jira/browse/SLING-11780?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17691105#comment-17691105
]
Roy Teeuwen commented on SLING-11780:
-------------------------------------
[~joerghoh] are you proposing to fix this on ResourceResolver level or on
JcrResourceProvider level? I don't see this working if you put the cache on
ResourceResolver and you'd have a ResourceProvider that takes specific cases to
return / not return null for the same path, seeing as the ResourceProvider
could be another one not backed by JCR so the cache purge events will not be
valid there
> Cache non-existing resources
> ----------------------------
>
> Key: SLING-11780
> URL: https://issues.apache.org/jira/browse/SLING-11780
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.10.0
> Reporter: Joerg Hoh
> Assignee: Joerg Hoh
> Priority: Major
>
> I found that in many situations various Sling features probe for the
> existence of resources, for example the Sling Servlet Resolution and also
> Sling Context-Aware Configuration. If these functions are called multiple
> times during the lifetime of a ResourceResolver, the ResourceResolver always
> checks for the presence of these resources and will consistently return
> "null" (non-existing resource).
> Due to the MVCC pattern we can cache the information that a resource does not
> exist at the ResourceResolver.
> To support changes performed to the Repository by this specific
> ResourceResolver, this cache should be purged by a modifying operations
> (move, copy, create, delete), but also on refresh.
> (Background: I found that for the rendering on a mildly complex AEM page
> (WKND sample content) I have 18 paths, for which the existence of a resource
> is tested more than 50 times and consistently returned "null". I expect that
> a caching of this information will save a good number of CPU cycles in Oak.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
