From users-return-311-apmail-jackrabbit-users-archive=jackrabbit.apache.org@jackrabbit.apache.org Wed Jun 28 17:16:13 2006 Return-Path: Delivered-To: apmail-jackrabbit-users-archive@locus.apache.org Received: (qmail 48891 invoked from network); 28 Jun 2006 17:16:13 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 28 Jun 2006 17:16:13 -0000 Received: (qmail 47080 invoked by uid 500); 28 Jun 2006 17:16:12 -0000 Delivered-To: apmail-jackrabbit-users-archive@jackrabbit.apache.org Received: (qmail 47066 invoked by uid 500); 28 Jun 2006 17:16:12 -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 47057 invoked by uid 99); 28 Jun 2006 17:16:12 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jun 2006 10:16:12 -0700 X-ASF-Spam-Status: No, hits=0.5 required=10.0 tests=DNS_FROM_RFC_ABUSE,HTML_MESSAGE,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of vijay.k.pandey@gmail.com designates 64.233.162.199 as permitted sender) Received: from [64.233.162.199] (HELO nz-out-0102.google.com) (64.233.162.199) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 28 Jun 2006 10:16:11 -0700 Received: by nz-out-0102.google.com with SMTP id r28so100450nza for ; Wed, 28 Jun 2006 10:15:51 -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:references; b=WHhVwq/uqSQGp7vVd9XPcIc93Zla1yMZVQjLyayAgBR7GPrvLcQ1dg8fr2W09omLE6sqjLgTuytPlFDHyib8kxkb4xaPXU3VlHYH4yhCvJQwa5+2WmE85612T/cmEgdgfLor5c0l3UbYcnti2c4FnmN6eN8jOZl1dq2r0VEfGeg= Received: by 10.36.105.17 with SMTP id d17mr1566748nzc; Wed, 28 Jun 2006 10:15:51 -0700 (PDT) Received: by 10.36.178.20 with HTTP; Wed, 28 Jun 2006 10:15:50 -0700 (PDT) Message-ID: <3ed4376e0606281015q27a2f604s22c4f704ba72157@mail.gmail.com> Date: Wed, 28 Jun 2006 12:15:50 -0500 From: "Vijay Pandey" To: users@jackrabbit.apache.org Subject: Re: Newbie Question - Performance In-Reply-To: <8a83c96b0606280959w16c6960cqbc98b1621f59f630@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_205_13714176.1151514950936" References: <3ed4376e0606280917v5a664491n887c86742c1aa746@mail.gmail.com> <8a83c96b0606280931k20d88e9cg501420327ca56742@mail.gmail.com> <3ed4376e0606280950y49e78b11s769d0e17d7c1f89c@mail.gmail.com> <8a83c96b0606280959w16c6960cqbc98b1621f59f630@mail.gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N ------=_Part_205_13714176.1151514950936 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline I am planning to use the jackrabbit( as a stand alone program - not running in app server) over the RMI, as the the same repository will be accessed by more than 1 application server basically Model 3 server deployment. In this case what do you suggest is the best way to do the session pool? If we do the session pool like using the commons-pool or something like that, do we need to do "logout" on session before it is returned to the pool? Or do you think JCA can be used in this scenario? Thanks Vijay On 6/28/06, Edgar Poce wrote: > > sorry, I meant "pool the session", I said connections because I was > thinking in terms of JCA where each session represents a connection to > the repository. > btw, if you use the jca connector you can delegate to the container > the pooling task. > > br, > edgar > > On 6/28/06, Vijay Pandey wrote: > > Thanks for the reply. > > > > When you say "pool the connection", do you mean to say pool the jcr > session > > ? > > For pooling the jcr session that means there should be no logout on the > jcr > > session? > > or after logout do we need to return to pool -- (but this doesnt make > sense) > > > > or do you mean to say pool the "jdbc connections" if we are using > > SimpleDBPersistenceManager for storing the content? > > > > Thanks > > Vijay > > > > > > On 6/28/06, Edgar Poce wrote: > > > > > > Hi, > > > > > > On 6/28/06, Vijay Pandey wrote: > > > > --------------------------------------------------------------- > > > > 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. > > > > ---------------------------------------------------------------- > > > > > > > > > > it's not thread safe, I think you should pool the connections somehow. > > > btw, I think that comment is out of date, I'll remove it. AFAIK it's > > > been a while since transient items are shared among read only > > > sessions. > > > > > > br, > > > edgar > > > > > > > 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 ? > > > > > > > > Thanks > > > > Vijay > > > > > > > > > > > > > > > > ------=_Part_205_13714176.1151514950936--