Bug #97850 jdbc42preparestatement cause memory leak
Submitted: 2 Dec 2019 14:57 Modified: 1 Sep 15:51
Reporter: lao xh Email Updates:
Status: No Feedback Impact on me:
None 
Category:Connector / J Severity:S3 (Non-critical)
Version:5.1.45 OS:SUSE
Assigned to: CPU Architecture:Any

[2 Dec 2019 14:57] lao xh
Description:
The method "StatementImpl.executeBatch()" create a "jdbc42preparestatemnent" which it never close when "useCursorFetch" is "true" and those statement create an exception. The statement registers itself with the connection and remains in the "openStatements" list forever.

How to repeat:
Properties props = new Properties();
props.setProperty("useSSL", "false");
props.setProperty("useServerPrepStmts", "true");
props.setProperty("rewriteBatchedStatements", "true");
props.setProperty("useCursorFetch", "true");
props.setProperty("defaultFetchSize", "100");
props.setProperty("user", "root");

Connection conn = (Connection) DriverManager.getConnection(dbUrl, props);props.setProperty("password", "root");

while(true) {
stm = conn.createStatement();
//abnormal SQL
for(;;){
stm.addBatch("INSERT INTO `sakila`.`city1`(`city`,`country_id`)VALUES('guangzhou',9);");}
stm.executeBatch();
}catch(SQLException e) {}finally{
if (stm != null) {stm.close();}
}
}

Suggested fix:
close those jdbc42preparestatement as no exception happened,when no exception happened,jdbc42preparestatement can be closed. jdbc42preparestatement is not created explicitly by a user,so it should be closed by jdbc.
[1 Aug 15:51] Filipe Silva
Hi lao xh,

I'm sorry for the late reply.

Thank you for this bug report and your interest in Connector/J.

Please review your test case because it clearly doesn't do anything since it loops endlessly in the `addBatch()` call, not to mention other syntax issues.

Please also try using Connector/J 8.0 and if you still observe some wrong behavior, please let us know.
[2 Sep 1:00] Bugs System
No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".