Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 59276 invoked from network); 29 Jun 2006 10:15:25 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 29 Jun 2006 10:15:25 -0000 Received: (qmail 72509 invoked by uid 500); 29 Jun 2006 10:15:25 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 72370 invoked by uid 500); 29 Jun 2006 10:15:24 -0000 Mailing-List: contact users-help@jackrabbit.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: users@jackrabbit.apache.org Delivered-To: mailing list users@jackrabbit.apache.org Received: (qmail 72361 invoked by uid 99); 29 Jun 2006 10:15:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jun 2006 03:15:24 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of the.mindstorm.mailinglist@gmail.com designates 66.249.92.172 as permitted sender) Received: from [66.249.92.172] (HELO ug-out-1314.google.com) (66.249.92.172) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 Jun 2006 03:15:23 -0700 Received: by ug-out-1314.google.com with SMTP id a2so245305ugf for ; Thu, 29 Jun 2006 03:15:01 -0700 (PDT) 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=ck70j3zh1TSkMm0Zs473zKdXRW4alx5intE1qwJ0eYI9wo5EHc4PzXJoWD/1/GKAl0dDF8+et2Nun5jdVU7XYLVLIiZ4au8Ikn8XZAaqdsF2tye8e9ploAN+sEx15OLZa8YzmPBUEayrYfMunbwKTDPG+XpFQkeTv8LDwoE6yJc= Received: by 10.67.93.6 with SMTP id v6mr1724016ugl; Thu, 29 Jun 2006 03:15:01 -0700 (PDT) Received: by 10.67.101.14 with HTTP; Thu, 29 Jun 2006 03:15:01 -0700 (PDT) Message-ID: Date: Thu, 29 Jun 2006 13:15:01 +0300 From: "Alexandru Popescu" To: users@jackrabbit.apache.org, tobias.bocanegra@day.com Subject: Re: Newbie Question - Performance In-Reply-To: <8be731880606290258i58817ffas6a5eef9045ed6c85@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> <8be731880606290258i58817ffas6a5eef9045ed6c85@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N On 6/29/06, Tobias Bocanegra 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? 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. ./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 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 wrote: > > > On 6/28/06, Ramachandra Sankuratri 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: > > > > > > > > > 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. > > > > > > > > > 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 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 >--- >