[
https://issues.apache.org/jira/browse/SLING-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13866419#comment-13866419
]
Konrad Windszus edited comment on SLING-3285 at 1/9/14 7:48 AM:
----------------------------------------------------------------
Hi Alex, thanks for your answer but how does the cache help then?
If we only talk about one request, there should never be parallel access in any
case, since the session was closed immediately afterwards (before the cache was
implemented), so there should be no overlap of open sessions (at least for the
case of isResourceType())
If we talk about multiple requests the cache will not help, because the cache
is per request (it means for n requests there might be n parallel sessions,
which is the same behaviour as before!).
Even without the cache we would have no more than n parallel sessions for n
requests. Am I wrong here?
was (Author: kwin):
Hi Alex, thanks for your answer but how does the cache help then?
If we only talk about one request, there should never be parallel access in any
case, since the session was closed immediately afterwards (before the cache was
implemented).
If we talk about multiple requests the cache will not help, because the cache
is per request (it means for n requests there might be n parallel sessions,
which is the same behaviour as before!).
Even without the cache we would have no more than n parallel sessions for n
requests. Am I wrong here?
> ResourceResolver.isResourceType() creates admin session for every call with
> super type, slowing down processing
> ---------------------------------------------------------------------------------------------------------------
>
> Key: SLING-3285
> URL: https://issues.apache.org/jira/browse/SLING-3285
> Project: Sling
> Issue Type: Bug
> Components: ResourceResolver
> Affects Versions: Resource Resolver 1.0.6
> Reporter: Alexander Klimetschek
> Assignee: Carsten Ziegeler
> Priority: Critical
> Labels: Performance
> Fix For: Resource Resolver 1.1.0
>
>
> SLING-2457 fixed the ACL issue with super type lookups, but at the cost of
> creating a new admin resource resolver for every super type lookup. If an
> inheritance chain contains multiple super types (N), a single call can
> trigger the creation of N admin sessions. Often this also happens for a
> number of resources per request, depending on the application, so you might
> end up creating many Jackrabbit JCR sessions per request. While creating a
> resource resolver / session is cheap, having too many at the same time has a
> big performance impact on the read performance due to increased concurrency
> in the JCR repository layer.
> This affects:
> * ResourceUtil.isA()
> * Resource.isResourceType()
> * ResourceResolver.isResourceType()
> * implementation in ResourceResolverImpl.isResourceType() and
> getParentResourceType() [1]
> A simple fix could be to cache a single admin resolver for the duration of
> the resource resolver containing it and reusing it for subsequent
> isResourceType() calls.
> Another improvement could also be to cache the isResourceType() lookups - if
> this is a typical short-lived request resource resolver. Within a request
> resource type hierarchies are unlikely to change and should probably be
> stable (and with Jackrabbit Oak the session won't refresh anyway). The cache
> would simply be a map of "resource type" => "is also this resource type", so
> that the super lookups don't have to be done again and again. Often an
> application might iterate over a tree of data and looking for the same
> resource type again and again, so the hit rate for the cache will be high.
> [1]
> https://svn.apache.org/viewvc/sling/trunk/bundles/resourceresolver/src/main/java/org/apache/sling/resourceresolver/impl/ResourceResolverImpl.java?revision=1537136&view=markup
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
