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
