sling-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Carsten Ziegeler <cziege...@apache.org>
Subject Re: ResourceResolver.getResource() semantics
Date Mon, 30 Sep 2019 06:51:09 GMT
I guess it's not the resource resolver calling getResource() but code 
using the resource resolver calling it over and over again, right?

It's correct that the javadoc does not state whether a new resource 
object is returned or a previous one. Client code should not make any 
assumptions about this. So you could return the same object.

Years ago I did a simple caching implementation for the same reasons you 
mention :) and although getResource was called over and over again with 
the same path during a single request, the caching did not provide any 
significant benefit as not getting the resource but the operations on 
the returned resource where the part where most time was spent. That 
might have changed, but its something to look at. And obviously instead 
of trying to implement lower level caching, its better to avoid the many 
calls in the first place.

Regards
Carsten

Am 30.09.2019 um 08:00 schrieb Jörg Hoh:
> Hi,
> 
> I am currently looking performance-wise on the resourceResolver; I found
> that during request handling a single resource resolver often calls
> getResource() for the same path. And before I start researching ways to
> optimize it (caching is quite obvious), I would like know about the
> detailed semantics of getResource().
> 
> Resource r1 = resourceResolver.getResource(path);
> Resource r2 = resourceResolver.getResource(path);
> 
> I haven't in the javadoc any statement about the relation between these
> two, especially if it's mandatory that r1 != r2 (which is the current
> implementation). If there are requirements towards this, I would try to
> come up with an implementation in which  r1 == r2.
> 
> WDYT?
> 
> Jörg
> 

-- 
--
Carsten Ziegeler
Adobe Research Switzerland
cziegeler@apache.org

Mime
View raw message