jackrabbit-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Edgar Poce" <edgarp...@gmail.com>
Subject Re: web based jcr browser contribution
Date Tue, 21 Nov 2006 21:09:21 GMT
On 11/21/06, Jukka Zitting <jukka.zitting@gmail.com> wrote:
> 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.
>

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
>

Mime
View raw message