jackrabbit-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ted Roeloffzen" <ted.roeloff...@gmail.com>
Subject Re: is jackrabbit Threadsafe?
Date Mon, 16 Oct 2006 11:39:07 GMT
we are planning to make a CMS using Wicket, maybe you've heard of it, and
JackRabbit. We'll start very simple, by creating a blog and expand it later

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.
>
> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message