> On Sat, Apr 19, 2008 at 1:33 AM, Tobias Bocanegra > <[EMAIL PROTECTED]> 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
