You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "John H. Embretsen (JIRA)" <de...@db.apache.org> on 2006/03/02 16:24:41 UTC

[jira] Commented: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed

    [ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12368518 ] 

John H. Embretsen commented on DERBY-210:
-----------------------------------------

Regarding patch derby-210-patch5-v1.diff:

I have not looked at the actual code, but I applied the patch to head of trunk and started to run some tests:

* I started the previously mentioned DOTS test against trunk + patch, with same settings (or as close as possible) as earlier. If it runs without error for longer than 55 hours, it will be an improvement. I will publish the results later.

* I created a smaller stand-alone application "inspired by" the really bad parts of the DOTS test, and got very promising results (using sane jars):

    * Without the patch, head of trunk (SVN 382319), OutOfMemoryError occured in the derby server JVM after executing a little more than 11000 "bad" SELECT statements.
    * With the patch applied, the the server JVM was able to garbage collect the PermSpace, and executed 100000 "bad" statements without error :)

I will do some more testing, but it's certainly looking good so far!  :)




> 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-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
>
> 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