Perhaps this is what you had in mind at the end of your last message, but
if all of your DAO objects inherit from a common base class (as they
should), why not add your connection opening logic to that class, add a
"closeConnection()" method as well, and then code like this in each of your
jsps:
><%
> 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...
bo.closeConnection();
>%>
You'd still have to modify all your jsps, but at least you don't have to
modify the DAO's... don't see any way around it if you want to do it properly.
justin
At 12:56 PM 8/21/2002, you wrote:
>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]>
