In the end, this primarily depends on the behavior of the underlying ResourceProviders that funnel into the ResourceResolver.
For instance, if the ResourceProvider(s) support MVCC, then the data available when the ResourceResolver was opened will be "stuck" to the moment in time it was opened at, not seeing any of the updated data since it was opened. One way to resolve this, as already suggested, is to receive the ResourceResolver as a parameter - this passes the burden of its life onto "someone else", making it "not your problem". Another way to resolve this is to call refresh() on the resolver instance periodically, so as to retrieve the updates of data in the system from other sources, if there are any. If the ResourceProvider(s) do not support MVCC (which usually means that refresh() actually does nothing) then a natural side effect is that one would get the updated system data automatically without needing to invoke refresh(). This route (not calling refresh and expecting updates to come in) is most usually error-prone, since the most commonly used provider, Oak, does support MVCC. The NoSQL providers likely do also support MVCC due to the underlying NoSQL server engines supporting MVCC, but not I've not confirmed this. On Wed, Jun 15, 2016 at 12:30 AM, Paul McMahon <oro...@yahoo.com.invalid> wrote: > I generally follow the practice of having the resource resolver passed in if > possible. If the whatever is calling the service is triggered by some sort of > HTTP request it's always best to just have the resource resolver passed in - > in which case the resource resolver is only around for the life the request > and gets disposed of automatically by the system. > If I do have to leverage a resource resolver that you get from the factory I > tend to try and dispose of them in the same method I created it. > Paul McMahon > From: Roy Teeuwen <r...@teeuwen.be> > To: users@sling.apache.org > Sent: Tuesday, June 14, 2016 11:19 AM > Subject: Using the resource resolver > > Hello all, > > I am wondering on the usage of the resource resolver and on how long it > should stay open. Lets say I have the following implementation: > > @Component > @Service(SomeService.class) > public class SomeServiceImpl implements SomeService { > > @Reference > private ResourceResolverFactory resourceResolverFactory; > > private ResourceResolver resourceResolver; > > @Activate > protected synchronized void activate(Map<String, Object> properties) > throws Exception { > try { > resourceResolver = > resourceResolverFactory.getAdministrativeResourceResolver(null); > } catch (LoginException e) { > LOG.error("Failed to get admin resourceresolver", e); > throw e; > } > } > > @Deactivate > protected synchronized void deactivate(Map<String, Object> properties) > throws Exception { > if (resourceResolver != null && resourceResolver.isLive()) { > resourceResolver.close(); > } > } > > public void doSomething(String path) { > Resource resource = resourceResolver.getResource(path); > //do something > } > } > > > Is there anything wrong on using this? Knowing that this means the > resourceresolver will stay open for possible months/years… > Or should one try and make the resourceresolver opening as short as possible? > Knowing that the method will be called around 1000-2000 times an hour. > > Another solution is of course passing the resourceResolver to do the > doSomething, but then the question still remains, how long should you keep a > resourceresolver open > > Greetings, > Roy > >