You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@jackrabbit.apache.org by Tobias Bocanegra <to...@day.com> on 2008/04/19 00:33:25 UTC
session pooling
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.
WDYT?
--
toby
Re: session pooling
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sun, Apr 20, 2008 at 9:50 PM, Felix Meschberger <fm...@gmail.com> wrote:
> Am Sonntag, den 20.04.2008, 20:41 +0200 schrieb Julian Reschke:
> > Furthermore, do you want to guarantee that future Jackrabbit versions
> > will behave the same way?
>
> Agreed. And on an application level which deals with JCR and uses
> Jackrabbit just because it is the best implementation available, I would
> even stick with the JCR spec stating that Sessions need not be
> thread-safe and thus assume Sessions are NOT thread-safe.
Agreed*2.
There was earlier some discussion on explicitly synchronizing all JCR
API calls on the related Session instance to ensure that none of the
session-local data structures need to be thread-safe.
BR,
Jukka Zitting
Re: session pooling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
Am Sonntag, den 20.04.2008, 20:41 +0200 schrieb Julian Reschke:
> Tobias Bocanegra wrote:
> >>> - 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.
> >>>
> >> > ...
> >>
> >> Hm. How is this going to work in a multi-threaded environment? The JCR spec
> >> doesn't give any guarantees...
> > that's true, but jackrabbit sessions are thread safe.
Are they really ?
>
> OK, but then it should be totally clear that this advice only applies to
> Jackrabbit.
>
> Furthermore, do you want to guarantee that future Jackrabbit versions
> will behave the same way?
Agreed. And on an application level which deals with JCR and uses
Jackrabbit just because it is the best implementation available, I would
even stick with the JCR spec stating that Sessions need not be
thread-safe and thus assume Sessions are NOT thread-safe.
Regards
Felix
Re: session pooling
Posted by Julian Reschke <ju...@gmx.de>.
Tobias Bocanegra wrote:
>>> - 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.
>>>
>> > ...
>>
>> Hm. How is this going to work in a multi-threaded environment? The JCR spec
>> doesn't give any guarantees...
> that's true, but jackrabbit sessions are thread safe.
OK, but then it should be totally clear that this advice only applies to
Jackrabbit.
Furthermore, do you want to guarantee that future Jackrabbit versions
will behave the same way?
BR, Julian
Re: session pooling
Posted by Tobias Bocanegra <to...@day.com>.
> > - 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.
> >
> > ...
>
> Hm. How is this going to work in a multi-threaded environment? The JCR spec
> doesn't give any guarantees...
that's true, but jackrabbit sessions are thread safe.
regards, toby
Re: session pooling
Posted by Julian Reschke <ju...@gmx.de>.
Tobias Bocanegra wrote:
> ...
> - 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.
> ...
Hm. How is this going to work in a multi-threaded environment? The JCR
spec doesn't give any guarantees...
BR, Julian
Re: session pooling
Posted by Felix Meschberger <fm...@gmail.com>.
Hi,
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.
>
> WDYT?
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
denied...
So, if you would go for a session pool, you might want to have a look at
an existing implementation... ;-)
Regards
Felix
Re: session pooling
Posted by Tobias Bocanegra <to...@day.com>.
> On Sat, Apr 19, 2008 at 1:33 AM, Tobias Bocanegra
> <to...@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
Re: session pooling
Posted by Jukka Zitting <ju...@gmail.com>.
Hi,
On Sat, Apr 19, 2008 at 1:33 AM, Tobias Bocanegra
<to...@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.
Agreed.
BR,
Jukka Zitting