You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jackrabbit.apache.org by Angelo Immediata <An...@libero.it> on 2007/03/05 17:57:34 UTC

Web Application repository session management

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



Re: [JCR Browser] Web Application repository session management

Posted by Stefan Guggisberg <st...@gmail.com>.
On 3/7/07, Michael Neale <mi...@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 <av...@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 <pa...@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 <An...@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.
> >
> >
>

Re: [JCR Browser] Web Application repository session management

Posted by Michael Neale <mi...@gmail.com>.
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?

On 3/7/07, avim <av...@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 <pa...@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 <An...@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.
>
>

Re: [JCR Browser] Web Application repository session management

Posted by avim <av...@timetoknow.org>.
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 <pa...@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 <An...@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.


Re: Web Application repository session management

Posted by Tobias Bocanegra <to...@day.com>.
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 <pa...@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 <An...@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 >---

Re: Web Application repository session management

Posted by Paul Eggerling-Boeck <pa...@yahoo.com>.
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 <An...@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
>
>
>