db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kathey Marsden (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
Date Sat, 18 Feb 2006 06:40:58 GMT
    [ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12366880 ] 

Kathey Marsden commented on DERBY-210:

Statement.finalize() comment says

 * This method cleans up client-side resources by calling markClosed().
 * It is different from close() method, which also does clean up on server.

and the comment for closeX() says
     * An untraced version of close(). This method cleans up client-side 
     * resources and also sends commands to network server to perform 
     * clean up. This should not be called in the finalizer.
     * @throws SqlException

I think that the closeX comment should be expanded a bit to talk about the other differences
between finalize() and closeX

Looking at writeCloseResultSets, where all the action is, it seems the difference between
finalize() and closeX() is closeX:
	1) Sends commands to the server to close the result sets.
	2) Sends commands to the server to close the result sets of the generated keys query.
	3) Sends a commit if autocommit is on and it is appropriate.
	4) Explicitly removes the statement from connection_.openStatements_  and CommitAndRollbackListeners_
 by passing true to markClosed.

Working backwards for finalizer(), as best I can tell,  the finalizer does not need to do
these things because  ...
	4) The fact that it is being garbage collected means it is not in connection_.openStatements
or CommitAndRollbackListners.
	3) It is not a good idea for the gc() to be sending commits.
	2) Not sure about these. How do they get cleaned up?
	1) Somehow all of this causes the  section to be reused. So, while we won't have immediate
cleanup on the server, it will happen if the section is reused.  Can you explain this process
a bit more?

I think these changes are good, but I do think the comments regarding the difference between
finalize() and closeX() need to be clearer. At first I thought adding a parameter to markClosed
for removeListners was confusing, but I think it is ok since we hopefully will be able to
get rid of these lists all together long term.

Thanks for your help understanding these changes.  I want to understand them well because
we are not currently able to test them until your next patch goes in, and problems with gc()
are always a bear to debug.

> Network Server will leak prepared statements if not explicitly closed by the user until
the connection is closed
> ----------------------------------------------------------------------------------------------------------------
>          Key: DERBY-210
>          URL: http://issues.apache.org/jira/browse/DERBY-210
>      Project: Derby
>         Type: Bug
>   Components: Network Client
>     Reporter: Kathey Marsden
>     Assignee: Deepa Remesh
>  Attachments: DOTS_ATCJ2_Derby-noPatch.png, DOTS_ATCJ2_Derby-withPatch.png, derby-210-patch1.diff,
derby-210-patch2.diff, derby-210-patch2.status, derby-210-patch3.diff, derby-210-patch4-v2.diff,
derby-210-patch4-v2.status, derby-210-v2-draft.diff, derby-210-v2-draft.status, derbyStress.java
> Network server will not garbage collect prepared statements that are not explicitly closed
by the user.  So  a loop like this will leak.
> ...
> PreparedStatement ps;
>  for (int i = 0 ; i  < numPs; i++)
> 	{
> 	 ps = conn.prepareStatement(selTabSql);
> 	 rs =ps.executeQuery();
> 	 while (rs.next())
> 	{
> 	    rs.getString(1);
> 	}
> 	rs.close();
> 	// I'm a sloppy java programmer
> 	//ps.close();
> 	}
> To reproduce run the attached program 
> java derbyStress
> Both client and server will grow until the connection is closed.
> It is likely that the fix for this will have to be in the client.  The client does not
send protocol to close the prepared statement, but rather reuses the PKGNAMCSN on the PRPSQLSTT
request once the prepared statement has been closed. This is how the server knows to close
the old statement and create a new one.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message