-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Richard,
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
everything.
| 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?
http://dev.mysql.com/doc/refman/5.0/en/cj-news.html
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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkiblQgACgkQ9CaO5/Lv0PBDhQCfX5Y2RkgxPChd2kGXlxQssMWE
CWkAn2JMpZbdm6knUqZSiWlE3grEepe6
=Qis0
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
