jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Alexandru Popescu" <the.mindstorm.mailingl...@gmail.com>
Subject Re: is jackrabbit Threadsafe?
Date Mon, 16 Oct 2006 14:54:31 GMT
On 10/16/06, Miro Walker <miro.walker@gmail.com> wrote:
> Another way to handle this is to create a pool of sessions and use
> them for different request threads. You avoid the creation overhead
> this way while still having per-thread sessions.
>
> Also worth noting that there are still some known bugs around
> concurrent access to versioning operations within transactions.
> Whether this will affect you depends on what you're planning to do of
> course.
>

Miro, I think I am remembering you posting about this JCR Session
pool. Is this a solution you have developed in house or is it
based/contributed back to the community?

tia,

./alex
--
.w( the_mindstorm )p.

> m
>
>
> On 10/16/06, Michael Neale <michael.neale@gmail.com> wrote:
> > Session creation seems to be fast after the first hit, fast enough for pre
> > request cycles. You can always wrap stuff with threadsafe code to protect
> > access if you want a per http session scenario.
> >
> > On 10/16/06, Ted Roeloffzen <ted.roeloffzen@gmail.com> wrote:
> > >
> > > But when you use different Sessions for all request cycles, you will have
> > > to
> > > login all the time and this will kill your performance, or am i wrong??
> > >
> > > On 10/16/06, Ted Roeloffzen <ted.roeloffzen@gmail.com> wrote:
> > > >
> > > > So how would you do it?
> > > >
> > > >
> > > > On 10/16/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com
>
> > > > wrote:
> > > > >
> > > > > On 10/16/06, Ted Roeloffzen < ted.roeloffzen@gmail.com> wrote:
> > > > > > So we don't have to create a variable for the JackRabbit session
in
> > > > > the
> > > > > > HTTP-session,
> > > > >
> > > > > I would say that this is in fact not recommended. Imagine what happens
> > > > > with 2 concurrent requests that are using the same HttpSession? Is
the
> > > > > JCR Session still used in a thread safe manner?
> > > > >
> > > > > ./alex
> > > > > --
> > > > > .w( the_mindstorm )p.
> > > > >
> > > > > > but we can use it in a request-cycle?? We are now using a
> > > > > > simple Abstract class en getting the session from it.
> > > > > >
> > > > > >
> > > > > >
> > > > > > On 10/16/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com>
> > > > > wrote:
> > > > > > >
> > > > > > > On 10/16/06, Ted Roeloffzen <ted.roeloffzen@gmail.com>
wrote:
> > > > > > > > So when using it in a Web-application, every HTTP-session
has to
> > > > > have
> > > > > > > its
> > > > > > > > own JackRabbit-session. So then it would be threadsafe?
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > > > I think you should think about it in request-scope and
not on Http
> > > > > > > session scope. Only request-response cycles are guaranteed
to
> > > happen
> > > > > > > on the same thread.
> > > > > > >
> > > > > > > ./alex
> > > > > > > --
> > > > > > > .w( the_mindstorm )p.
> > > > > > >
> > > > > > > > On 10/16/06, Tobias Bocanegra < tobias.bocanegra@day.com>
wrote:
> > > > > > > > >
> > > > > > > > > if every thread uses it's own jcr session, yes.
> > > > > > > > > regards, toby
> > > > > > > > >
> > > > > > > > > On 10/16/06, Ted Roeloffzen <ted.roeloffzen@gmail.com>
wrote:
> > > > > > > > > > I would really like to know if JackRabbit
is threadsafe.
> > > > > > > > > >
> > > > > > > > > > Greets,
> > > > > > > > > >
> > > > > > > > > > Ted
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > >
> > > > > > > > >
> > > > > > > > > --
> > > > > > > > > -----------------------------------------<
> > > > > 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>---
> > > > > > > > >
> > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > >
> > >
> >
> >
>

Mime
View raw message