You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@jackrabbit.apache.org by Apache Wiki <wi...@apache.org> on 2008/04/22 01:24:26 UTC
[Jackrabbit Wiki] Update of "JcrSessionHandling" by TobiasBocanegra
Dear Wiki user,
You have subscribed to a wiki page or wiki category on "Jackrabbit Wiki" for change notification.
The following page has been changed by TobiasBocanegra:
http://wiki.apache.org/jackrabbit/JcrSessionHandling
New page:
= Guide for JCR session handling =
[[TableOfContents(3)]]
== Intro ==
In a J2EE environment there is usually a question how to deal with JCR sessions in respect to the http requests and/or the http sessions. basically we can distinguish 2 cases: ''personalized'' or ''anonymous'' access in respect to the jcr session. personalized means here, that a http users is mapped to a repository user (in order to enforce access control).
further more it can be distinguished between read-only and read/write access. the later with an edge case where a session needs to keep the transient changes over several http requests (e.g. a JCR browser).
below some rules on how to use sessions, with the assumption that JCR sessions are '''not''' thread safe (as specified by JSR-170).
=== basic rules ===
* never put the JCR sessions directly into the http sessions, since if you have a lot of http sessions, you end up having a lot of jcr sessions which might consume a lot of memory.
* never share JCR sessions among requests, since they could not be thread safe.
=== read-only access, guest accounts ===
* create a session for each request, or use a non-coupled session pool.
=== read-only access, personalized accounts ===
* create a session for each request, or use a user-coupled session pool (especially if authentication is expensive).
=== read/write access, personalized accounts ===
* create a session for each request, or use a user-coupled session pool (especially if authentication is expensive).
=== read/write access, transient mods ===
this is the only case where JCR sessions should be bound (but not stored in) http sessions.
* create a JCR session for each http session, but be careful that you don't have them open too long, especially if you expect a lot of http sessions.
== Discussion ==
http://www.nabble.com/session-pooling-to16777157.html