OK. That was helpful. Thanks guys.
On Thu, Sep 29, 2011 at 3:10 PM, Bertrand Delacretaz <[email protected]> wrote: > Hi, > > On Thu, Sep 29, 2011 at 2:09 PM, Markus Joschko > <[email protected]> wrote: >> 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 > > All true AFAIK, ResourceResolvers are probably threadsafe by > themselves but use JCR sessions which are not. > > Actually, reading from sessions from multiple threads is safe, it's > writing concurrently that's not ok. > >> >> -> Sessions and Resolvers should not be stored as instance members but >> opened and closed in the in the process/handleEvent methods. > > If you're reading only you can use a session concurrently. > If you're writing rarely you can synchronize on the session object > when writing for example. > >> >> 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? > > Jackrabbit session creation is cheap, the idea is that you can create > a session on every HTTP request for example. > > IMO synchronizing might cause more performance and latency issues as > creating new sessions as needed, but it depends on your usage patterns > I guess. I'd start with whatever feels right and measure response > times as needed. > > -Bertrand >
