Session Handling | Community
Skip to main content
Jai1122
February 19, 2021
Solved

Session Handling

  • February 19, 2021
  • 2 replies
  • 2695 views

Hi Experts,

  I am writing a Sling Component which a Servlet can use to read and write properties from and to the repository.

Since there are many custom properties and each property updation will be mapped to a different method, is it advisable to initiate the resource resolver in the activate method of the component and then use it to adapt the session object in each method. Below code is a sample.

 

@8220494 public class RepoUtil{ private ResourceResolver resourceResolver; private javax.jcr.Session session; @Activate @Modified public void activate(final ComponentContext componentContext) { //initialize the configuration props resourceResolver = getResourceResolver(); } public String getPropertyAFromNodeA(){ session = resourceResolver.adaptTo(Session.class); //use session to get the node needed. // use node api to get the intended property return propertyvalue; } public String getPropertyBFromNodeA(){ session = resourceResolver.adaptTo(Session.class); //use session to get the node needed. // use node api to get the intended property return propertyvalue; } public String updatePropertyAFromNodeA(){ session = resourceResolver.adaptTo(Session.class); //use session to get the node needed. // use node api to update the intended property return propertyvalue; } }

 

Note that session is not closed at the end of each method. Since I am not creating the session object instead merely adapting it from resource resolver, I am not sure if the session object has to be closed.  Is there a pattern we can use in scenarios like this where multiple reads/writes are expected?

 

Regards,

Pal

This post is no longer active and is closed to new replies. Need help? Start a new post to ask your question.
Best answer by davidjgonzalezzzz

100% don't initialize a resource resolver in your activate method. Keep your ResourceResolvers/JCR Sessions short-lived as you can. Also, rememeber resourceResolvers and JCR Sessions are NOT thread-safe. So if you had a servlet being hit by 2 ppl at the same time, and they both invoke the RepoUtil service using the same resourceResolver, bad things will happen (like end up w/ lost data due to unresolvable state conflicts)

 

Here's what you should do (in order of generic preference),

 

1. Pass in the slingRequest's resourceResolver to your OSGi component's methods to read/write the properties. This way you are using the actual user's security context (permissions) to write the data. This is the preferred approach.

2. If for some reason you cannot allow for the user of the sling requests's resource resolver to write the data, obtain a Service User resourceResolver with the proper permissions in your Servlet, and pass it to your methods.  

3. You could alternatively obtain the Service User resource resolver in your RepoUtil, and get a new resourceResolver in each method, but obviously thats a bit wasteful (if the servlet calls 3 methods, then you'd be obtaining the same resourceResolver 3x)

 

Also, try to avoid using JCR APIs when you can use Sling APIs, I'm specifically saying here you should use SLing Resources and ValueMaps (and ModifiableValueMaps) over JCR Nodes and Properties. If all your RepoUtil does is a "dumb" read/write of JCR properties, it seems unnucessary. If you had a domain-specific OSGi Service, such as "ContactUsService" and you pass in a bunch of data to something like contantUsService.submit(email, name, message) .. and that service puts those 3 params in the "right place" in the JCR, that makes more sense. Just having a OSGI component that generically reads/writes properties doesn't strike me as useful and redundant of Sling's APIs.

 

https://experienceleague.adobe.com/docs/experience-manager-learn/foundation/development/understand-java-api-best-practices.html?lang=en

2 replies

davidjgonzalezzzzAdobe EmployeeAccepted solution
Adobe Employee
February 19, 2021

100% don't initialize a resource resolver in your activate method. Keep your ResourceResolvers/JCR Sessions short-lived as you can. Also, rememeber resourceResolvers and JCR Sessions are NOT thread-safe. So if you had a servlet being hit by 2 ppl at the same time, and they both invoke the RepoUtil service using the same resourceResolver, bad things will happen (like end up w/ lost data due to unresolvable state conflicts)

 

Here's what you should do (in order of generic preference),

 

1. Pass in the slingRequest's resourceResolver to your OSGi component's methods to read/write the properties. This way you are using the actual user's security context (permissions) to write the data. This is the preferred approach.

2. If for some reason you cannot allow for the user of the sling requests's resource resolver to write the data, obtain a Service User resourceResolver with the proper permissions in your Servlet, and pass it to your methods.  

3. You could alternatively obtain the Service User resource resolver in your RepoUtil, and get a new resourceResolver in each method, but obviously thats a bit wasteful (if the servlet calls 3 methods, then you'd be obtaining the same resourceResolver 3x)

 

Also, try to avoid using JCR APIs when you can use Sling APIs, I'm specifically saying here you should use SLing Resources and ValueMaps (and ModifiableValueMaps) over JCR Nodes and Properties. If all your RepoUtil does is a "dumb" read/write of JCR properties, it seems unnucessary. If you had a domain-specific OSGi Service, such as "ContactUsService" and you pass in a bunch of data to something like contantUsService.submit(email, name, message) .. and that service puts those 3 params in the "right place" in the JCR, that makes more sense. Just having a OSGI component that generically reads/writes properties doesn't strike me as useful and redundant of Sling's APIs.

 

https://experienceleague.adobe.com/docs/experience-manager-learn/foundation/development/understand-java-api-best-practices.html?lang=en

Jai1122
Jai1122Author
February 19, 2021
Thanks for your response. One more question, what about session. Should it be closed every time I get it?
joerghoh
Adobe Employee
Adobe Employee
February 20, 2021

There are a few things to note here:

* An OSGI component is a singleton, thus your Resource Resolver is used on every invocation. And as Resource Resolvers are not thread-safe, you are likely to run into problems. To fix that you can either require that on every invocation of your service's method a ResourceResolver is provided, which is then used. The other way to solve is to create a dedicated ResourceResolver for every of these invocations. The same applies for JCR Sessions.

* Why do you use the JCR API? In 99% of all cases you can achieve the same with the Sling Resource API.

 

To answer your question: if you use resourceResolver.adaptTo(Session.class), you don't open the session. I have answered that question more deeply here: https://cqdump.wordpress.com/2018/11/12/resourceresolvers-and-sessions-you-open-it-you-close-it/

 

HTH,

Jörg

 

 

 

joerghoh
Adobe Employee
Adobe Employee
February 21, 2021
Hi, if you work on a custom authentication handler, you can check the 2 authentication provider implementations which already ship with Sling (see https://sling.apache.org/documentation/the-sling-engine/authentication/authentication-authenticationhandler.html). I haven't implemented a custom auth handler yet, so my practical advice is limited.