Hi, Michael's answer is right, typically you bound one session to one request. Creating a session, especially with an embedded repository, is very fast. But note that there is no automatic mechanism against concurrent changes from two parallel sessions. Normally the second update wins (if there is no conflict). You can use locking for synchronization or versioning (see the JCR spec [1]). And in most cases, a clear content structure [2] will help in avoiding conflicts in most cases.
Regards, Alex [1] http://jcp.org/en/jsr/detail?id=170 [2] http://wiki.apache.org/jackrabbit/DavidsModel On Tue, Sep 9, 2008 at 7:35 AM, Krohne, Frank - ENCOWAY <[EMAIL PROTECTED]> wrote: > Hi, > > > > we are developing web applications and now want to use jackrabbit as > contend repository. > > > > So the question is, what is the preferred way to handle the jackrabbit > sessions in an web application. > > When to open a new session and when to close the session and when to > write (save) contend to it and to be sure other users don't have > modified the nodes another user is modifying at the moment? > > Should we open a new session on every request or share a session on the > same http session? > > Are the jackrabbit sessions thread safe? > > If we bind the sessions to our own users (self implemented user > management) what is the best way to know when to close the jackrabbit > session if the user doesn't log out or has multiple http sessions open? > > > > So we are new to jackrabbit and the docs about are rare to this topic (I > think). > > > > It would be great to get some hints or tips on how to handle jackrabbit > sessions in a web application. > > > > Thanks in advance > > > > Frank > > -- Alexander Klimetschek [EMAIL PROTECTED]
