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: Newbie Question - Performance
Date Thu, 29 Jun 2006 10:34:05 GMT
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.

> 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