tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Schultz <>
Subject Re: Would like to monitor memory use offline
Date Fri, 08 Aug 2008 00:36:24 GMT
Hash: SHA1


Richard S. Huntrods wrote:
| In my code I was calling resultSet.close(), but not statement.close().

That'll do it.

| The problem is, even though I verified (debug statements) that the call
| is being made, the memory is STILL not being released. If I run the same
| large query 3 times in a row, my memory use triples. Even if I log off
| the session (my application) and invalidate the session, the memory is
| still locked up and cannot be freed by the JVM.

Can you post some (sanitized) code? Maybe you're still missing something.

Remember that you can't just close the statement when you're done with
your method... if you use multiple Statements and ResultSets, you have
to close them as you so. You also have to make sure that you have a
finally block that closes them in case of an exception condition.

I've posted it before, but I'll to it again because it bears repeating:
here is the proper way to write JDBC code:

	Connection conn = null;
~        PreparedStatement ps = null;
~        ResultSet rs = null;

~        try
~        {
~            conn = getConnection(); // however you get your connections

~            ps = conn.prepareStatement(...);  // your query

	    // set params, etc.

~            rs = ps.executeQuery();

	    // do whatever you need to do with your ResultSet
~        }
~        finally
~        {
	    if(null != rs) { rs.close(); } catch (SQLException sqle)
	    { /* log this error! */ }
	    if(null != ps) { ps.close(); } catch (SQLException sqle)
	    { /* log this error! */ }
	    if(null != conn) { conn.close(); } catch (SQLException sqle)
	    { /* log this error! */ }
~        }

I wrote a method in a utility class that does everything in the finally
block -- it makes the code much easier to read IMO.

Note that if you need multiple Statements, you should either use them
serially, and close each statement before you move onto the next one
(and re-use the local variable), or you should define them all outside
of the try/finally block and make sure they are closed under all
conditions. If you don't do this, you'll leak memory.

If you are using transactions, remember that you must catch /every
exception that can possibly occur/ (yes, even Errors and
RuntimeExceptions) and make sure you do a rollback before you close

| So what am I missing? I was sure that adding the code to close my
| statements would fix the problem.

Is it possible that the code you're looking at is good, but some other
code has a similar leak but is yet to be fixed.

| So - does anyone know what the major change was between 3.0.17 and
| 3.1.10 that would have such a dramatic effect?

It's possible that newer versions of the JDBC driver more properly
adhere to the JDBC specification which results in memory leakage
(because JDBC expects you to code in very rigid ways, including cleaning
up your own memory messes ;).

I use mysql-connector-5.0.8.jar and have not had a problem in a very
long time.

- -chris
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla -


To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message