[
http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12366856 ]
Kathey Marsden commented on DERBY-210:
--------------------------------------
Firstly Deepa, let me say I am sorry I did not get to look at this part of the
big patch when it was first posted.
I think I need a little more background on the two lists in questions before I
can review.
Connection.openStatements_ and Connection.CommitAndRollbackListeners_
Why are they needed?
If they are needed....
What are they used for?
What is added and when?
What is removed and when (finalize/close/some other time)
The descriptions of both lists seem to describe things that I question.
The statements do not need to be reprepared on the server after
commit/rollback.
I also don't understand why the resultset would be unpositioned.
//DERBY prepared statements must be re-prepared after a commit
// then we must traverse this list after a commit and notify statements
// that they are now in an un-prepared state.
final java.util.LinkedList openStatements_ = new java.util.LinkedList();
// Some statuses of DERBY objects may be invalid on server
// after both commit and rollback. For example,
// (1) prepared statements need to be re-prepared
// after both commit and rollback
// (2) result set will be unpositioned on server after both commit and
rollback.
// If they depend on both commit and rollback, they need to get on
CommitAndRollbackListeners_.
final java.util.LinkedList CommitAndRollbackListeners_ = new
java.util.LinkedList();
> 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
