Bug #8848 Possible Memory Leak
Submitted: 28 Feb 2005 17:55 Modified: 28 Feb 2005 18:09
Reporter: Daniel Pereira Email Updates:
Status: Not a Bug Impact on me:
None 
Category:Connector / J Severity:S2 (Serious)
Version:3.1.7 OS:Tested on XP and Linux (Red Hat)
Assigned to: CPU Architecture:Any

[28 Feb 2005 17:55] Daniel Pereira
Description:
Hello,
    I detected that, if the statements of the queries weren't close when using the Connector/J3.1.7 the application crash with the error "java.lang.OutOfMemory". But when using the Connector/J 3.0.16 this doesn't happen, it sees that the old version closes automaticaly all the Statements that weren't used (or close faster this statements).

This is a feature or a bug ?
    
Mysql v4.1.10
Java 1.4.2 and 1.5

Best regards,

Daniel Pereira

How to repeat:
Basicaly create infinite while which make the same query and don't close the Statement. You will see that the memory of the application will grow until it doesn't have more memory, because it uses all the resources.

Suggested fix:
Close all open statements, like suggested on the "Connector/J manual"
[28 Feb 2005 18:09] Mark Matthews
This behavior is required by the JDBC specification. Statements are 'alive' until you either close them, or the connection closes them. 

To do this, the driver needs to maintain a reference to any open statement instance, even after it has left your application's scope. Unfortunately, finalizers are being discouraged by Sun and others, as they impact GC throughput, so the answer is not to add a finalizer to these classes to automatically close them if the application forgets to do so. Given that starting with MySQL-5.0, PreparedStatements may have server-side references, implementing a finalizer that would close the server resources as well is a recipe for deadlock.

You should close open statements yourself (as is required by the JDBC specification), or if you have an application that does a bad job of this, use 'dontTrackOpenResources=true' in your JDBC url, which will cause the JDBC driver to not be in compliance with the JDBC specification, but will cause the driver not to keep track of statements on a per-connection basis, so that once an instance of a statement goes out of scope, it is free to be GC'd.