On 11.09.2012, at 08:24, Sam Lee <skyn...@gmail.com> wrote: > Which AdapterFactory implements > resourceResolver.adaptTo(javax.jcr.Session.class) ?
I think it's the JcrResourceProvider, with the adaptTo being "forwarded" from the jcr resource resolver: http://svn.apache.org/viewvc/sling/trunk/bundles/jcr/resource/src/main/java/org/apache/sling/jcr/resource/internal/helper/jcr/JcrResourceProvider.java?view=markup > I am doing a lot of this in servlet that handles POST request: > slingRequest.getResourceResolver().adaptTo(Session.class).save(); > > And, I get a lot of > Caused by: org.apache.jackrabbit.core.state.StaleItemStateException: > 4d530d2b-c3a2-4dd4-9e41-4d515f2a1bf8/itemTagged has been modified externally This means session A tries to update something that another session B modified in the meantime (between session A reading the item and trying to write it). This could be due to concurrent requests - if you only use the request jcr session as with resolver.adaptTo(Session.class) mentioned above. In which case this is normal. But maybe you also create a second session in parallel in the same request and use them both at the same time? > I am pretty sure I'm not managing Session and persisting properly in POST > request handler. > > Is there a guideline (and example) for managing Session and persistence? By default, use the request session only. You get access control (session uses the request user) and usually you only want one transaction per request. If you have concurrent requests modifiying the same nodes, you have to think about avoiding that on a high level (e.g. jcr locks although they can be tricky) or retrying the failed change automatically. HTH, Alex