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