On Thu, Sep 29, 2011 at 3:16 PM, Carsten Ziegeler <cziege...@apache.org> wrote: > I wouldn't rely on concurrent reads with the same session. In rare > cases this can lead to problems!
Do you have more info about that? (not disputing, just curious) -Bertrand > 2011/9/29 Bertrand Delacretaz <bdelacre...@apache.org>: >> Hi, >> >> On Thu, Sep 29, 2011 at 2:09 PM, Markus Joschko >> <markus.josc...@gmail.com> 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 >> > > > > -- > Carsten Ziegeler > cziege...@apache.org >
