Guide for JCR session handling
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.