[
https://issues.apache.org/jira/browse/SLING-10269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17313107#comment-17313107
]
Joerg Hoh commented on SLING-10269:
-----------------------------------
In https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/43
[~rombert] mentioned the aspect "write operations", which is currently not
properly reflected. The new cache is invalidated when the resourceresolver is
refreshed and on commit, but it cannot detect this case:
{code}
ResourceResolver rr = ...;
Session session = rr.adaptTo(Session.class);
...
session.save();
{code}
If during this operation relevant resources/nodes are modified, which influence
the {{resourceType}}/{{resourceSuperType}} handling, these updates are ignored.
On the other hand side, the
[JcrValueMap|https://github.com/apache/sling-org-apache-sling-jcr-resource/blob/master/src/main/java/org/apache/sling/jcr/resource/internal/JcrValueMap.java]
handles it the same way.
How should we proceed with that? From a strict compatibility point of view we
are breaking it (it worked before this change), but I am not sure about the
severity of this issue, especially given that the JcrValueMap behavior has most
likely a larger impact as this one.
> cache results of isResourceType()
> ---------------------------------
>
> Key: SLING-10269
> URL: https://issues.apache.org/jira/browse/SLING-10269
> Project: Sling
> Issue Type: Improvement
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.7.2
> Reporter: Joerg Hoh
> Assignee: Joerg Hoh
> Priority: Major
> Time Spent: 3h 20m
> Remaining Estimate: 0h
>
> I have code, which uses {noformat}resourceResolver.isResourceType(Resource,
> String){noformat} very often to determine type information. I also observed,
> that the execution time of this method contributes a lot to the overall
> execution time.
> Also the number of unique resourcetypes which are going to be checked
> (resource.getResourceType, 1st parameter) is typically quite low; the same
> applies for the number of resourcetypes it is compared against. So it makes
> sense to cache the result of that method call in map which shares the
> lifetime of the ResourceResolver, as the result will never change during this
> lifetime. But during a refresh() this map can be cleared, so any changes in
> the RT hierarchy which might have happened will get effective.
> I have tested this approach already and it gives a significant speedup to my
> code (reduced execution time by 50%); of course this cannot be expected
> universally, as this is an extreme case, but it shows that there is indeed a
> bit of overhead.
> https://github.com/apache/sling-org-apache-sling-resourceresolver/pull/43
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
