jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: session pooling
Date Sun, 20 Apr 2008 08:36:05 GMT

On Sat, Apr 19, 2008 at 1:33 AM, Tobias Bocanegra
<tobias.bocanegra@day.com> wrote:
>  - in a pure read-only env (i.e. the requests do not write back content
>  to the repository), never put the jcr sessions directly into the http sessions.
>  reason: if you have a lot of http sessions, you end up having a lot
>  of jcr sessions which might consume a lot of memory.

To back that up, each JCR session starts at roughly 9kB and grows as
the per-session caches get filled up.

>  - in a pure read-only env, start with 1 session for each request or
>  share the same session among all requests. if you think this could be
>  a performance problem, implement a static or dynamic session pool.

Starting a session is a relatively lightweight operation, costing
about 1.3 ms and the above-mentioned 9kB on my laptop. Session pooling
could be used to get rid of that millisecond.

There are also the per-session caches that would probably benefit from
session pooling, but I'm not sure how big an improvement that is given
that the repository-wide SharedItemStateManager cache already covers
the most expensive parts of retrieving item states.

Personally I'd avoid introducing a session pool until I have a
benchmark that shows clear benefits from using it. Alternatively, we
might want to look at ways of improving the session startup time in
Jackrabbit (I think we could push it down to 10-100 us).

>  - in a mostly read-only env with request-local write back, either use
>  1 session per request, or a dynamic session pool. important is, that
>  sessions must not be shared among requests at the same time
>  (concurrency issues).

I'd go for a session per request, especially for requests that write
something to the repository.

>  - in a r/w env where you need to keep transient changes present over
>  several requests, you can assign a jcr session to a http session, but
>  be careful that you don't have them open too long, if you expect a lot
>  of http sessions.



Jukka Zitting

View raw message