Every method will have to get it's own connection and close it too. > -----Original Message----- > From: Christian J. Dechery [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, August 21, 2002 2:56 PM > To: [EMAIL PROTECTED] > Subject: Re: problems with Connections > > > That's exactly the problem... we dont't have any servlets (I > wish we had, but I didn't design, I only code)... only JSPs > and classes... > > I'll give u an example of how are things here... let's say we > have a class called BusinessObject, and a class called > DAOBusinessObject... > > so I'd have a JSP like that > > <% > BusinessObject bo = new BusinessObject(); // at this > point, DAOBusinessObject requested a connection > bo.method1(); // this method calls a method in DAO which > runs a query > bo.method2(); // this on too... and every other method as well... > %> > > so, as long as the DAOBusinessObject object "lives" the > Connection is there... how am I supposed to close it, since > every query needs it? Now I see, I should have a method to > close the used conn or something... but we have up to 50 DAO* > classes and more then 200 JSPs... > > I agree with what u said about the finalize()... but what > should I do then? > > > .:| Christian J. Dechery > .:| FINEP - Depto. de Sistemas > .:| [EMAIL PROTECTED] > .:| (21) 2555-0332 > > >>> [EMAIL PROTECTED] 21/08/02 16:37 >>> > > > On Wed, 21 Aug 2002, Christian J. Dechery wrote: > > > Date: Wed, 21 Aug 2002 16:13:23 -0300 > > From: Christian J. Dechery <[EMAIL PROTECTED]> > > Reply-To: Tomcat Users List <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: Re: problems with Connections > > > > I don't think it is TOTALLY offtopic, since the problem > occurs within > > Tomcat... > > From your description of the problem and your design > approach, I'll bet it > would happen to you in a long-running non-servlet application as well. > > and when I close tomcat all the connections and cursors are > > released... > > > > Exactly what you'd expect if your application is leaking open > connections, > statements, or result sets. > > > as I said in my email I close ALL ResultSets and Statements > in "finally" > > blocks... > > > > Fine, I'll take your word for it ... but missing a case would easily > account for what you are seeing. (In the particular case of Oracle, a > cursor is allocated for each result set, which is not > released until the > result set is closed). > > > as for "closing" the Connection... can I use the finalize() > in the DAO* > > classes to use the method that returns the Connection to > the pool?? Cuz > > I can't see anywhere else where I'd be able to do that... > > > > The right design pattern is to acquire a connection, do whatever > processing is required, and immediately release it. For example: > > DataSource dataSource = ...; // Acquire reference to > connection pool > Connection conn = null; > try { > conn = dataSource.getConnection(); > ... perform SQL operations as necessary ... > conn.close(); // Return connection to the pool > conn = null; > } catch (SQLException e) { > ... deal with problems ... > } finally { > if (conn != null) { > try { > conn.close(); // Return to pool even if an exception occurred > } catch (SQLException e) { > ; > } > conn = null; > } > } > > Waiting for the finalize() method to clean up just occupies resources > needlessly until the garbage collector gets around to running -- this > by itself could easily exhaust your available connections in a busy > environment. It also assumes that your JDBC driver's > implementation of > the finalize() method knows that this Connection was stored in a pool. > That seems like a really shaky bet. > > A primary goal of your designs should be to minimize the > amount of time > that you have a database connection allocated to the processing of a > particular request -- connections are expensive to create, and there's > always an upper limit on how many your database will support. > > > .:| Christian J. Dechery > > .:| FINEP - Depto. de Sistemas > > .:| [EMAIL PROTECTED] > > .:| (21) 2555-0332 > > Craig > > > -- > To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
-- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
