My co-worker has implemented using the Jakarta Commons Pool, and it works
nicely. I would recommend trying that to see if it fits your needs.
Jukka Zitting wrote:
>
> Hi,
>
> On Nov 21, 2007 6:15 PM, Paco Avila <[EMAIL PROTECTED]> 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).
>
> BR,
>
> Jukka Zitting
>
>
--
View this message in context:
http://www.nabble.com/Sharing-a-Session-or-a-Session-per-web-user-tf4851166.html#a13954712
Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
