Don’t miss the AEM Skill Exchange in SF on Nov 14—hear from industry leaders, learn best practices, and enhance your AEM strategy with practical tips.
SOLVED
SlingException - Resource resolver is already closed
1 Accepted Solution
Correct answer by
Hi
I was reading an article, and got some information related to your problem.
//
Do not share nodes, resources and pages between threads and requests.
You might run into the case, that you need to share data between multiple threads or requests. A simple example for this is HTTP-Session or a cache which stores data you need to share between multiple or all incoming requests.
In such cases do not store nodes, pages or DAM assets or any other object based on a node or a resource in that cache. Each of these objects belongs to a certain session (or resource resolver instance), and they are not valid anymore if this session is logged out or if the resource resolver is closed; if you still try to execute methods on them, you will run into exceptions.
If you want to share such data, share objects which are not bound to any Session. So instead of putting pages in there, put the path to the page there instead. If you need the page again then, just use your own ResourceResolver, resolve it to a resource and adapt it to a page. You still can run into access control issues, if the second resources resolver does not see that node due to ACL constraints. In such a case you should think about your application design.
Another article as a reference link :- http://tech.ethomasjoseph.com/2015/09/sling-who-is-closing-my-jcr-session.html
//you should rely on Sling objects as much as possible, rather than relying directly on the JCR objects. But at those cases (e.g. writing to a repository) when you will have to directly rely on the JCR repository you will have to still use the JCR Session, its recommended that you directly get the JCR session from the Sling repository, and not adapt it from the ResourceResolver, IF you do not intend to use the ResourceResolver directly.
I hope this would help you.
Thanks and Regards
Kautuk Sahni
Kautuk Sahni
Correct answer by
Hi
I was reading an article, and got some information related to your problem.
//
Do not share nodes, resources and pages between threads and requests.
You might run into the case, that you need to share data between multiple threads or requests. A simple example for this is HTTP-Session or a cache which stores data you need to share between multiple or all incoming requests.
In such cases do not store nodes, pages or DAM assets or any other object based on a node or a resource in that cache. Each of these objects belongs to a certain session (or resource resolver instance), and they are not valid anymore if this session is logged out or if the resource resolver is closed; if you still try to execute methods on them, you will run into exceptions.
If you want to share such data, share objects which are not bound to any Session. So instead of putting pages in there, put the path to the page there instead. If you need the page again then, just use your own ResourceResolver, resolve it to a resource and adapt it to a page. You still can run into access control issues, if the second resources resolver does not see that node due to ACL constraints. In such a case you should think about your application design.
Another article as a reference link :- http://tech.ethomasjoseph.com/2015/09/sling-who-is-closing-my-jcr-session.html
//you should rely on Sling objects as much as possible, rather than relying directly on the JCR objects. But at those cases (e.g. writing to a repository) when you will have to directly rely on the JCR repository you will have to still use the JCR Session, its recommended that you directly get the JCR session from the Sling repository, and not adapt it from the ResourceResolver, IF you do not intend to use the ResourceResolver directly.
I hope this would help you.
Thanks and Regards
Kautuk Sahni
Kautuk Sahni
