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

Reply via email to