jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Felix Meschberger <fmesc...@gmail.com>
Subject Re: session pooling
Date Sun, 20 Apr 2008 18:48:22 GMT

Am Freitag, den 18.04.2008, 15:33 -0700 schrieb Tobias Bocanegra:
> hi,
> i want to gather some input about how to use jcr sessions in a
> web-like environment. so, if a script/servlet that responds to a
> request needs to read/write to a repository. of course this largely
> depends on the use case. but here are some rules i want to verify:
> - 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.
> - 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.
> - 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).
> - 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.

Besides avoiding HttpSessions altogether because they are bad ;-)

Not sure about the session setup time - I did some informal times a long
time ago, which showed bad (i.e. long) session setup times. So I went
for Session pooling. This Session pool implementation is now part of the
Sling jcr/base module. Thus Sling has always been using pooled sessions.
As a side effect, this may even be used to a certain degree to limit
system access: If limit of the pool has been exhausted furhter access is

So, if you would go for a session pool, you might want to have a look at
an existing implementation... ;-)


View raw message