Update February 2023: Updated the list of API calls, which create a new Sling ResourceResolver (see this Forum thread). Thanks NitroHazeDev!
I have already written about how to use resource resolvers and JCR sessions; the basic pattern to remember is always “you open it; you close it” (2nd rule).
While this stanza seems to be quite commons sense, the question is always: When is a session or a resource resolver opened/created? What API calls are responsible for it? Let me outline this today.
API calls which open a JCR resource:
API calls, which create a Sling ResourceResolver
- ResourceResolverFactory.getAdministrativeResourceResolver(), DEPRECATED!
- ResourceResolverFactory.getResourceResolver()
- ResourceResolverFactory.getServcieResourceResolver()
- WorkflowSession.adaptTo(ResourceResolver.class)
These are the only API calls which open a JCR Session or a Sling ResourceResolver. And whenever you use one of these, you are responsible to close them as well.
And as corollary to this rule: if you have other methods or APIs which return a ResourceResolver or Session: Do not close these.
Some examples:
Session jcrSession = resourceResolver.adaptTo(Session.clase);
This just exposes the internal JCR Session of the ResourceResolver and because it’s not using one of the above APIs: Do not close this session! It’s closed automatically when you close the resource resolver.
Session adminSession = slingRepository.loginAdministrative(null); Map authInfo = new HashMap(); authInfo.put(org.apache.sling.jcr.resource.api.JcrResourceConstants.AUTHENTICATION_INFO_SESSION, session); ResourceResolver adminResourceResolver = resolverFactory.getResourceResolver(authInfo);
This code creates a resource resolver which wraps an already existing JCR Session. You have to close both adminSession and adminResourceResolver, because you created them both using the above mentioned API calls.