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 Wed, 08 Mar 2006 22:19:58 GMT
    [ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12369555 ] 

Kathey Marsden commented on DERBY-210:

Committed  'derby-210-patch5-v1.diff' 

Date: Wed Mar  8 13:16:49 2006
New Revision: 384331

URL: http://svn.apache.org/viewcvs?rev=384331&view=rev

Thank you so much Deepa for all your hard work on this issue and Bryan and John too.
I talked with Deepa on IRC about the outstanding issues and possible organization of Jira
issues, moving forward:

The current oustanding issues seem to be:
a) Prepared statements are not garbage collected on the server until the sections  are reused.
 (This I think has to be fixed with a DRDA protocol Change)
b) ResultSets are not garbage collected on the server until the  section is  reused.  (This
could be fixed with  DERBY-1021)
c) John found an issue with Statements not getting cleaned up at least on the server.

Would this  sound like a reasonable course of action?
1) Open a subtask of this issue with the work Deepa has done so far and close it. Something
"Change the client driver to allow statements to be garbage-collected once they are dereferenced
by an application" 
2) Open a subtask of DERBY-210 for item "a"  above.
3) Open a new  issue for "b"  to replace  DERBY-1021. DERBY-1021 could be a part of that issue
or just closed.
4) Open a new issue for "c"



Would the following sound like a reasonable course of action moving forward:

1) Close DERBY-1021 and replace it with a subtask of this issue that is more specific, like:

> 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, StatementStress.java,
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-patch4-v3.diff, derby-210-patch4-v3.status,
derby-210-patch5-v1.diff, derby-210-patch5-v1.status, derby-210-v2-draft.diff, derby-210-v2-draft.status,
derbyStress.java, runtimeinfo_DOTS-OOME.txt
> 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