[
https://issues.apache.org/jira/browse/SLING-3285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13848469#comment-13848469
]
Carsten Ziegeler commented on SLING-3285:
-----------------------------------------
There are at least three reasons :)
- the jcr spec states that a session should not be a accessed concurrently -
and we don't want to rely on implementation details
- the resource resolver spec states it should not be accessed concurrently -
and we're accessing an admin resource resolver which has an underlying session
- although Jackrabbit states that its safe to have concurrent read access, at
least in previous versions of Jackrabbit, there were sporadic problems with
this resulting in exceptions. This might be fixed with newer versions of
Jackrabbit
> 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.4#6159)
