jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stefan Guggisberg" <stefan.guggisb...@gmail.com>
Subject Re: [JCR Browser] Web Application repository session management
Date Wed, 07 Mar 2007 10:19:37 GMT
On 3/7/07, Michael Neale <michael.neale@gmail.com> wrote:
> yeah I think pooling sessions keyed on user id won't work for a large number
> of concurrent users. assuming you keep a cap on your cache, then basically
> there would be very little of the same user staying in the cache.
>
> However, for a small number of users and a complex app - I spose this can
> work?
>
> I too and a little concerned of this caching in the session - is there a way
> to pull it out to a threadsafe place?

i don't know what you mean by 'caching in the session'.

however, please note that Session not being thread-safe
is not a jackrabbit-specific limitation, see e.g.
"7.5 Thread-Safety Requirements" in the jsr 170 spec.

btw: although not officially supported you probably could
share *read-only* sessions among multiple threads.
you certainly can't do that if your threads perform write
operations.

cheers
stefan

>
> On 3/7/07, avim <avi.moradi@timetoknow.org> wrote:
> >
> >
> > Do you have any recommended pooling framework/strategy?
> > Since it seems to be a must for almost every application, are there any
> > plans to make it a built-in layer like jdbc datasource?
> > Where can I find explanation/detailed documentation about caches?
> >
> > Tobias Bocanegra wrote:
> > >
> > > i think it really depends on the sort of application. but consider
> > > that sessions are not designed to be thread safe, so give at least
> > > every request it's own session, but of course you can pool them (key =
> > > credentials). creating the session itself is very cheep, but it hold
> > > several caches that help speedup things later on. if you don't pool
> > > the sessions your application will probably be slower. also bear in
> > > mind, that because of those caches, every session needs memory, so
> > > it's not a good thing to pool thousands of sessions.
> > >
> > > regards, toby
> > >
> > > On 3/5/07, Paul Eggerling-Boeck <paulboeck@yahoo.com> wrote:
> > >> I'm also a newbie so keep that in mind when reading this.  Seems to me
> > >> that you want a new Session each time (especially if you're working
> > >> with user-restricted access levels), but to keep the Repository object
> > >> around to be shared, essentially as a Session factory.  Sort of like
> > >> the Hibernate model.
> > >>
> > >> Paul
> > >>
> > >> On 3/5/07, Angelo Immediata <AngeloImm@libero.it> wrote:
> > >> > Hi.
> > >> >
> > >> > I'm newbie in JCR. What i'm wondering is: is it correct to do a
> > lookup
> > >> session search for every operation into an web application? Or is it
> > >> better to have only once the session and work always with this object?
> > >> >
> > >> > Thanx to all.
> > >> > Bye
> > >> >
> > >> >
> > >> > ------------------------------------------------------
> > >> > Mutui da 200.000 euro? Tassi ridotti da 4.25% solo per richieste
> > >> online. Mutuionline.it
> > >> > http://click.libero.it/mutuionline5mar07
> > >> >
> > >> >
> > >> >
> > >>
> > >
> > >
> > > --
> > > -----------------------------------------< tobias.bocanegra@day.com >---
> > > Tobias Bocanegra, Day Management AG, Barfuesserplatz 6, CH - 4001 Basel
> > > T +41 61 226 98 98, F +41 61 226 98 97
> > > -----------------------------------------------< http://www.day.com >---
> > >
> > >
> >
> > --
> > View this message in context:
> > http://www.nabble.com/Web-Application-repository-session-management-tf3350135.html#a9332620
> > Sent from the Jackrabbit - Users mailing list archive at Nabble.com.
> >
> >
>

Mime
View raw message