jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: Sharing a Session or a Session per web user
Date Mon, 26 Nov 2007 16:38:49 GMT

On Nov 21, 2007 6:15 PM, Paco Avila <pavila@git.es> wrote:
> Our application using Jackrabbit is an Document Management System
> (OpenKM). Actually we prevent an user log into the web aplication twice,
> so there is only one Jackrabbit Session per web user.

Note that binding a JCR session to a HTTP session might still be
troublesome, as the Servlet API allows a single session to have
multiple concurrent HTTP requests. I would recommend either using
separate JCR sessions per each HTTP request or explicitly
synchronizing all JCR session access in your application.

> But we also expose several methods via WebServices and here is the
> problem: if an user is logged into the web application, the same user
> can't user WebService API because he is already logged into the system.

For such cases I would recommend using separate JCR sessions per each request.

>  - Reuse an existing Jackrabbit Session for both web user and the same
> ws api user. PROBLEM: is it a good practice for Jackrabbit?

You can do that, but my recommendation is then to explicitly
synchronize access to the JCR session in your application. Something
like this:

    // your application code
    synchronized (session) {
        ... // any code that uses the JCR session

This will obviously become a bottleneck if you want to concurrently
serve multiple requests for the same user.

>  - The web user hace one JR Session and the ws api user have another
> session. PROBLEM: Every web user need another WS user and this can be
> hard to manage because we need to set permissions for both users and
> should be the same permissions for them.

There's no reason why you could not open multiple sessions for a
single user. You could have separete web user and ws api user sessions
for the same JCR user account, or even start separate sessions for
each individial HTTP request.

The only functional benefit from keeping a JCR session across
individual HTTP requests is that you can then use the transient space
to manage unsaved changes (for example an uncommitted shopping cart).

If startup overhead of a JCR session is a problem for your
application, you can also consider using a session pool.
Unfortunately, as of now Jackrabbit doesn't come with a built-in
session pool implementation, but implementing one using something like
commons-pool shouldn't be too difficult (assuming you have some
control over the behaviour of your application).


Jukka Zitting

View raw message