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: Newbie Question - Performance
Date Thu, 29 Jun 2006 10:35:55 GMT
On 6/29/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> On 6/29/06, Stefan Guggisberg <stefan.guggisberg@gmail.com> wrote:
> > On 6/29/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com> wrote:
> > > On 6/29/06, Tobias Bocanegra <tobias.bocanegra@day.com> wrote:
> > > > the creation of the session is indeed lightweight. but there are
> > > > caches attached to the session that increase performance (especially
> > > > the CachingHierarchyManager). whenever you close (i.e. logout) the
> > > > session, you loose the cached information.
> > > >
> > > > in a web-based environment, with anonymous, access, i would have a
> > > > pool of connected (i.e. logged-in) jcr-sessions, that are used for
> > > > every request. this pool can have the size of 1, as long you are only
> > > > doing read-only access.
> > > >
> > >
> > > This sounds at the first glance interesting, but if the session keeps
> > > caching nodes as different anonymous users are browsing around isn't
> > > this gonna make the Session continuously grow?
> >
> > jackrabbit uses memory-sensitive caches. take a look at
> > o.a.j.core.state.ItemStateReferenceCache for an example.
> >
> > >
> > > On the other hand, this looks pretty particular to Jackrabbit
> > > implementation, because I don't think that the spec is mentioning
> > > anything about caching the already loaded nodes.
> >
> > jackrabbit is an *implementation* of the jsr 170 spec. caching is
> > an *implementation detail* that's why it's not mentionend in the
> > spec.
> >
>
> That's exactly my point.

huh? i think you lost me.

cheers
stefan

>
> > btw: any reasonable implementation will use some sort of caching.
> >
>
> Theoretically I agree with you on this. But, as long as it is not part
> of a spec, than it is an implementation detail.
>
> For example, with a persitence solution based on embedded objectual
> DB, the responsibility of caching may be moved to the DB layer.
>
> Please don't take me wrong. I am just trying to figure out what is the
> best thing to do.
>
> ./alex
> --
> .w( the_mindstorm )p.
> ---
> (http://themindstorms.blogspot.com)
>
>
> > cheers
> > stefan
> > >
> > > ./alex
> > > --
> > > .w( the_mindstorm )p.
> > > ---
> > > (http://themindstorms.blogspot.com)
> > >
> > > > as soon you have write access, possible several modifications over
> > > > multiple requests, with a 'save' at the end, you need to attach the
> > > > jcr-session to the j2ee-session, so that the transient changes don't
> > > > get lost, or mixed up with different users.
> > > >
> > > > the simplest model, however is to complete every transaction in one
> > > > request, creating and destroying one session for this purpose.
> > > >
> > > > regards, toby
> > > > On 6/29/06, Alexandru Popescu <the.mindstorm.mailinglist@gmail.com>
wrote:
> > > > > Hi!
> > > > >
> > > > > Sorry for jumping to this discussion, but I am a little bit confused
> > > > > by the comments (not those regarding Jackrabbit particular
> > > > > implementation). My understanding till this moment is that Session
> > > > > creation is not an expensive operation and so it is safe to open/close
> > > > > a session for each user. Moreover, in case the Session-s are mostly
> > > > > used in terms of read-only opperations I really don't see how my
> > > > > understanding would be contradicted. I feel that it is more dangerous
> > > > > the start to use Session in synchronized mode.
> > > > >
> > > > > As a quick note, my understanding (and not only mine, because I
> > > > > discussed this with different people working/involved with JCR in
the
> > > > > past) is that JCR Session is somehow very similar to Hibernate
> > > > > Session.
> > > > >
> > > > > Is my understanding/expectation completely wrong? If yes, than why?
> > > > >
> > > > > ./alex
> > > > > --
> > > > > .w( the_mindstorm )p.
> > > > > ---
> > > > > (http://themindstorms.blogspot.com)
> > > > >
> > > > >
> > > > > On 6/29/06, Stefan Guggisberg <stefan.guggisberg@gmail.com>
wrote:
> > > > > > On 6/28/06, Ramachandra Sankuratri <ramachandra.sankuratri@plateau.com>
wrote:
> > > > > > > Hi
> > > > > > >
> > > > > > >  If it has to support *read and write access* for multiple
users, does
> > > > > > > this mean that a new session has to be created for each
user?
> > > > > >
> > > > > > yes, unless you synchronize the access to the shared Session
> > > > > > and all dependant objects (Workspace, Node, Property etc.).
> > > > > >
> > > > > > note that this is not a jackrabbit-specific limitation;
> > > > > > see "7.5 Thread-Safety Requirements" of the jsr 170 spec:
> > > > > >
> > > > > > <quote>
> > > > > > As a consequence, an application which concurrently or sequentially
> > > > > > operates against objects having affinity to a particular Session
> > > > > > through more than one thread must provide synchronization sufficient
> > > > > > to ensure no more than one thread concurrently operates against
that
> > > > > > Session and changes made by one thread are visible to other
threads.
> > > > > > </quote>
> > > > > >
> > > > > > cheers
> > > > > > stefan
> > > > > >
> > > > > > >
> > > > > > > Thanks
> > > > > > > Chandu
> > > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Stefan Guggisberg [mailto:stefan.guggisberg@gmail.com]
> > > > > > > Sent: Wednesday, June 28, 2006 12:57 PM
> > > > > > > To: users@jackrabbit.apache.org
> > > > > > > Subject: Re: Newbie Question - Performance
> > > > > > >
> > > > > > > On 6/28/06, Vijay Pandey <vijay.k.pandey@gmail.com>
wrote:
> > > > > > > >  Hi,
> > > > > > > >
> > > > > > > > I am planning to use Jackrabbit and for a great #
of users we only
> > > > > > > need to
> > > > > > > > provide read only access and i was reading on the
wiki section abvout
> > > > > > > > performance, it says that
> > > > > > > > ---------------------------------------------------------------
> > > > > > > >  it's a good practice to share a single anonymous
session for read
> > > > > > > only
> > > > > > > > access if possible, it would reduce the time that
write actions will
> > > > > > > take.
> > > > > > > > ----------------------------------------------------------------
> > > > > > > >
> > > > > > > > Does it mean to say that 'session' is thread safe
at method level for
> > > > > > > read
> > > > > > > > only operations , or do we have to synchronize the
call on session? or
> > > > > > > do
> > > > > > > > you think should we have a pool of read only sessions
?
> > > > > > >
> > > > > > > you can assume that Session (at least the jackrabbit implementation)
> > > > > > > is thread-safe if it is used for *reading only*.
> > > > > > >
> > > > > > > cheers
> > > > > > > stefan
> > > > > > >
> > > > > > > >
> > > > > > > > Thanks
> > > > > > > >  Vijay
> > > > > > > >
> > > > > > > >
> > > > > > > The information contained in this e-mail message is intended
only for the personal
> > > > > > > and confidential use of the recipient(s) named above. This
message is privileged
> > > > > > > and confidential. If the reader of this message is not
the intended recipient or an
> > > > > > > agent responsible for delivering it to the intended recipient,
you are hereby notified
> > > > > > > that you have received this document in error and that
any review, dissemination,
> > > > > > > distribution, or copying of this message is strictly prohibited.
> > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > >
> > > >
> > > > --
> > > > -----------------------------------------< 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