Return-Path: Delivered-To: apmail-cayenne-user-archive@www.apache.org Received: (qmail 53556 invoked from network); 21 Sep 2010 21:34:58 -0000 Received: from unknown (HELO mail.apache.org) (140.211.11.3) by 140.211.11.9 with SMTP; 21 Sep 2010 21:34:58 -0000 Received: (qmail 1865 invoked by uid 500); 21 Sep 2010 21:34:58 -0000 Delivered-To: apmail-cayenne-user-archive@cayenne.apache.org Received: (qmail 1760 invoked by uid 500); 21 Sep 2010 21:34:57 -0000 Mailing-List: contact user-help@cayenne.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@cayenne.apache.org Delivered-To: mailing list user@cayenne.apache.org Received: (qmail 1750 invoked by uid 99); 21 Sep 2010 21:34:57 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Sep 2010 21:34:57 +0000 X-ASF-Spam-Status: No, hits=0.7 required=10.0 tests=RCVD_IN_DNSWL_NONE,SPF_NEUTRAL X-Spam-Check-By: apache.org Received-SPF: neutral (athena.apache.org: local policy) Received: from [209.85.214.43] (HELO mail-bw0-f43.google.com) (209.85.214.43) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 21 Sep 2010 21:34:51 +0000 Received: by bwz16 with SMTP id 16so18975bwz.16 for ; Tue, 21 Sep 2010 14:34:28 -0700 (PDT) Received: by 10.204.77.137 with SMTP id g9mr8087753bkk.189.1285104868385; Tue, 21 Sep 2010 14:34:28 -0700 (PDT) MIME-Version: 1.0 Received: by 10.204.103.78 with HTTP; Tue, 21 Sep 2010 14:34:08 -0700 (PDT) In-Reply-To: <38703.95.93.134.16.1285103249.squirrel@webmail.holos.pt> References: <55558.95.93.134.16.1285093356.squirrel@webmail.holos.pt> <54326.95.93.134.16.1285095835.squirrel@webmail.holos.pt> <38703.95.93.134.16.1285103249.squirrel@webmail.holos.pt> From: Michael Gentry Date: Tue, 21 Sep 2010 17:34:08 -0400 Message-ID: Subject: Re: Child Contexts To: user@cayenne.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Hi Bruno, In a typical deployment to Tomcat/JBoss/etc, you would use JNDI and let the container manage the database connections. It sounds to me like you are doing a lot of hot redeploys (not restarting Tomcat) and somehow the resources aren't being cleared up correctly for you. With JNDI, the container should manage the database connection externally to your hot redeploy. JNDI doesn't actually return a DataContext, but it'll return a database connection to a DataContext. And the DataContext will give it back to Tomcat's connection pool when done. There are numerous settings for Tomcat on how to manage the database connection pool for you. Usually you would tell it to keep at least 1 open connection (minIdle) to the database, but that is configurable by you. Check the Tomcat docs for setting it up. mrg On Tue, Sep 21, 2010 at 5:07 PM, wrote: > I'm using the regular way, through the Cayenne's DataNode XML file. But I > am open to suggestions :). I was thinking about configuring a global > resource on tomcat using JNDI that would return a DataContext, but i dont > know if everytime an application access the resource a new object is > created? > > Thank you > >> What are you using to provide your DB Connection Pool: JNDI, DBCP, or >> Cayenne? =A0What version of Cayenne are you using? >> >> mrg >> >> >> On Tue, Sep 21, 2010 at 3:03 PM, =A0 wrote: >>> Hey Michael and Robert, >>> >>> Ok so i got the difference between context and connection. So how can i >>> close all connections before closing an application, a servlet or a >>> portlet? My main problem here is that on each deploy of a new web >>> application the connections from former deployments stay on (like memor= y >>> leaks), and i need to close them or at least use one pool for the whole >>> site. >>> >>> I was thinking about putting the Context on the HTTPSession of the >>> application server or making a context that is used permanently by the >>> server... Any ideas how to do it on liferay or tomcat? >>> >>> Thank you >>> Bruno >>> >>>> Hi Bruno, >>>> >>>> The Child DataContext *might* share the same database connection as >>>> the Parent DataContext. =A0In general, you don't care about this, >>>> though. =A0The DataContext, on commitChanges(), will request a databas= e >>>> connection, use that connection for performing the commit, then return >>>> the connection back to the pool. =A0It isn't required that the same >>>> database connection be used between a performQuery() and a >>>> commitChanges(). >>>> >>>> If you do commitChanges() on a Child DataContext, it pushes the >>>> changes to the Parent DataContext and to the database. =A0If you only >>>> want the changes to go to the Parent DataContext and *not* the >>>> database, use commitChangesToParent(). >>>> >>>> mrg >>>> >>>> >>>> On Tue, Sep 21, 2010 at 2:22 PM, =A0 wrote: >>>>> Hello all, >>>>> >>>>> Do Child Contexts share the connection of a parent connection? When i >>>>> do >>>>> a >>>>> commitChanges on the child the change is made on the database or in >>>>> the >>>>> parent? I have already read the Nested Contexts page on the User Guid= e >>>>> but >>>>> this detail was confusing for me. >>>>> >>>>> Thank you >>>>> Bruno >>>>> >>>>> >>>> >>> >>> >>> >> > > >