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]>
