Hi, yes, a jcr session is not thread safe - this is more or less due to the spec not mandating thread safety for a session. Therefore a resource resolver is not thread safe either
Event handlers and job processors should be thread safe, therefore you're right that you should not share a resource resolver or session inside such a method. As far as I know, creating a session is a lightweight operation today (that used to be different), so I think you should be able to create a new session on every call. Its better than syncing. Especially as the event handling requires to process the method as fast as possible and if the processing of an event requires heavy operations it should do that async. Regards Carsten 2011/9/29 Markus Joschko <[email protected]>: > I want to get some assumptions of mine clarified regarding the usage > of classes like Session and ResourceResolver in event handlers. > > 1. The jackrabbit session is not threadsafe > 2. ResourceResolvers are not threadsafe > 3. Event services (EventHandler, JobProcessor, > javax.jcr.observation.Eventlistener) can be called concurrently > > -> Sessions and Resolvers should not be stored as instance members but > opened and closed in the in the process/handleEvent methods. > > If this is true, how expensive is the creation of a session? I read in > a blog, that the creation is considered expensive and wonder if it > makes more sense > to create the session new every time (and we have quite a lot of > events processed by the handlers), or to synchronize access to an > instance session? > > Regards, > Markus > -- Carsten Ziegeler [email protected]
