jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jukka Zitting" <jukka.zitt...@gmail.com>
Subject Re: web based jcr browser contribution
Date Tue, 21 Nov 2006 20:46:14 GMT
Hi,

On 11/21/06, Edgar Poce <edgarpoce@gmail.com> wrote:
> On 11/21/06, Jukka Zitting <jukka.zitting@gmail.com> 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.

> 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.

BR,

Jukka Zitting

Mime
View raw message