tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Craig R. McClanahan" <craig...@apache.org>
Subject Re: problems with Connections
Date Wed, 21 Aug 2002 19:37:02 GMT


On Wed, 21 Aug 2002, Christian J. Dechery wrote:

> Date: Wed, 21 Aug 2002 16:13:23 -0300
> From: Christian J. Dechery <christian@finep.gov.br>
> Reply-To: Tomcat Users List <tomcat-user@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> 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
> .:| christian@finep.gov.br
> .:| (21) 2555-0332

Craig


--
To unsubscribe, e-mail:   <mailto:tomcat-user-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:tomcat-user-help@jakarta.apache.org>


Mime
View raw message