[
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:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
