On 11/21/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
On 11/21/06, Edgar Poce <[EMAIL PROTECTED]> wrote:
> On 11/21/06, Jukka Zitting <[EMAIL PROTECTED]> wrote:
> > Should we target at eventually merging the two webapps, or is it
> > better to keep them separate?
>
> IMHO it's better to keep them separated, when the navigator is mature
> enough to join to the jackrabbit release cycle we could review it.
Agreed. My question was more about the eventual plan for the navigator
app than making immediate decisions. Let's revisit the issue later.
> > It would probably be good to come up with some best practice on how
> > access a JCR session from a servlet or a JSP page.
> >
> > Note that unless we use a SynchronizedSession decorator, it's better
> > if the JCR session is placed in request scope than in the session
> > scope to avoid problems with concurrent requests.
>
> I think the jcr-navigator app should not bind the jcr session to the
> request scope, a SynchronizedSession seems a better option for this
> scenario.
The SynchronizedSession idea has the same drawbacks as using a
Repository instance as a facade for a session pool. Since the JCR API
is interlinked in many places (e.g. Session.getItem().getSession())
and the thread-safety requirements cover not only the Session instance
but all other instances acquired through that session, it is not
enough to simply create a synchronizint decorator just for the Session
interface. Instead, we'd need to decorate the entire API to achieve
correct semantics. There's a partially implemented decorator layer in
JCR-EXT, but that effort got stalled as I realized the amount of
required overhead.
Thus I'd rather see the webapp explicitly synchronizing access to the
JCR session.
agreed.
> Currently, the user logs in via Container managed security, a
> ServletFilter logs in the given user in jackrabbit with an empty
> password and stores the jcr session in the http session. when the http
> session is invalidated a SessionListener is responsible of logging out
> the jcr session
The problem with associating the JCR session with the HTTP session is
that the servlet container may allow multiple concurrent request
within the same session.
yes. It was an issue I was aware and wanted to discuss the fix.
If I understand you correctly, in your previous post you proposed to
store the credentials and create a new connection on each request, I'd
prefer to keep a single jcr session. What do you think about storing
the jcr session in the servlet session and use a requestlistener to
synchronize the access to the jcr session?. On each request a lock
would be acquired on the jcr session and released only when the
request is over. This wouldn't allow two request to access the session
simultaneously.
br,
edgar
BR,
Jukka Zitting
