Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm
Precedence: bulk
Reply-To: users@jackrabbit.apache.org
Received-SPF: pass (asf.osuosl.org: domain of stefan.guggisberg@gmail.com
 designates 64.233.184.236 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=TZQguP9Sgkl3jbrkUJaXE4NLKaJurmw/9TCeavPob4+JDf4cZMJtJzp1XJjS/j7g1sTsJKGyVV+D6xlC/Wz496OGp11TbBt0i54WYVCrn0lk7gXkQzQs1MsxH4VVopu5fE+yk3Z5tGf8e1WMh+C3UxX9Aod/6AkqD7mXXmt3T2o=
Message-ID: <90a8d1c00606290325q332eca4fmbc841a9fc83bd0d3@mail.gmail.com>
Date: Thu, 29 Jun 2006 12:25:20 +0200
From: "Stefan Guggisberg" <stefan.guggisberg@gmail.com>
To: users@jackrabbit.apache.org
Subject: Re: Newbie Question - Performance
In-Reply-To: <c6f400460606290315h13a3eeb9xc0dad5c391a1ca43@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <90a8d1c00606280956n68e80086ia9c4da26b370bb21@mail.gmail.com>
	 <517054A82E55C7408B8FD9C8D76324CD06C0630E@email.plateau.internal>
	 <90a8d1c00606290026s1f7631a9m3fa41ff625ec9982@mail.gmail.com>
	 <c6f400460606290041x6f4d007evf76bf2ba59534501@mail.gmail.com>
	 <8be731880606290258i58817ffas6a5eef9045ed6c85@mail.gmail.com>
	 <c6f400460606290315h13a3eeb9xc0dad5c391a1ca43@mail.gmail.com>

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.

btw: any reasonable implementation will use some sort of caching.

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 >---
> >
>