jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Tobias Bocanegra" <tobias.bocane...@day.com>
Subject Re: session pooling
Date Sun, 20 Apr 2008 17:27:36 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.
yes, and this is my only concern, that the caches get filled up, and
then hang around in http sessions for a long time although not used
anymore.

>  >  - 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).
or provide some session-pool for request binding in jackrabbit.

>  >  - 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.
ack.

>  >  - 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.
>
>
> Agreed.

--
regards, toby

Mime
View raw message