db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Deepa Remesh (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 Sun, 19 Feb 2006 03:48:26 GMT
    [ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12366947 ] 

Deepa Remesh commented on DERBY-210:

Kathey, please see if the following answers your questions:

2) Not sure about these. How do they get cleaned up?
The statement and result sets for generated keys query get cleaned up in Statement.markClosed()
by call to markPreparedStatementForAutoGeneratedKeysClosed() method. This method calls markClosed
on the auto-generated keys statement, which will ensure this statement and its result sets
are cleaned on client side. The cleanup on server happens when section is re-used.

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? 
As part of Statement.markClosed(), markClosedOnServer() method gets called. This method frees
up the Section on the client. A stack is used to store the free sections. Hence, client driver
will use this freed section for the next statement. When client driver re-uses the freed section,
network server will find a statement with this section in its stmtTable and re-use the statement.
This happens in Database.newDrdaStatement method in network server. Before re-using the statement,
its close method is called. This close method cleans up the statement state and its current
result set. All other resultsets in its result set table are freed. 

If you find these explanations are correct, I'll upload a revised version of patch4 with more

As you said, the code in patch4 will be not be fully covered by tests currently. The code
in finalize method will be covered only after the patch which removes the memory leaks is
reviewed and committed. This is in my next patch (patch5 - which removes the memory leaks
+ enable derbyStress test). I will run tests with patch4 + patch 5 and submit patch5, if that
will help testing/reviewing.

I think it would be good to do a long running test with patch4+patch5 before committing them.
I'll be running the repro derbyStress.java with 1M prepared statements and will check client
and server memory usage. Other than that, it may be good to run the patch through DOTS test.
I do not have the DOTS setup. I would appreciate if John or anyone else has the setup for
DOTS and will be willing to run the tests after I upload the new patches. Anyone has suggestions
for other tests I can run to test this?

> 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:
For more information on JIRA, see:

View raw message