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
>
>
