db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (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 Fri, 10 Feb 2006 04:38:00 GMT
    [ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12365834 ] 

Daniel John Debrunner commented on DERBY-210:
---------------------------------------------

My gut feeling is that this single patch is trying to do too much (10 described items). If
any of these steps are independent I would strongly encourage you to submit them as separate
patches. Looks like step 2) for example is independent and possibly a low risk change.
Separate patches are good, they are easier to review, easier to explain, easier to manage
during development as if you have several sets of changes in a client built on top of each
other then as you code and re-code the most recent step you run the risk of corrupting the
earlier changes. Getting the individual pieces out there earlier also gives them more exposure
in the code line to additional testing and inspection. More people are likely to see the changes
when they are in the code than when they are in a patch file.

> 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-v2-draft.diff,
derby-210-v2-draft.status, derby-210.diff, derby-210.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


Mime
View raw message