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 Mon, 19 Dec 2005 17:38:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12360845 ] 

Deepa Remesh commented on DERBY-210:

To recap the problem: 
If PreparedStatement objects are not explicitly closed by user, they do not get garbage collected.
They remain alive in the client driver even after the user application does not have any reference
to them. The corresponding objects in network server are also not garbage collected.  

On looking at the client code, in addition to the reference returned to the user application,
PreparedStatement objects are referenced at following places:
1. In org.apache.derby.client.am.Connection, they are added to a java.util.LinkedList 'openStatements_'
2. Another reference is stored in NetStatement and NetPreparedStatement. 

Thanks to Bernt and Kathey for suggestion to use WeakReference. I changed these to use WeakReferences
and then I can see the PreparedStatement objects are getting finalized and collected both
at client and server side. I could run >32K prepared statements without calling close.
Before this change, I could run only ~950 statements before I get OutOfMemory error.  

For #1, using WeakReference seems to be the solution to me. But for #2, I was thinking if
there is any other way we can avoid having cross references between Statement and NetStatement.
One thing which I am not clear about is the structure of Statement classes. I see that NetConnection
and NetResultSet extend Connection and ResultSet classes in client.am. But in case of Statement,
the Net*Statement classes do not extend the corresponding Statement classes. They implement
MaterialStatement interface. When constructing new Statement objects, a NetStatement object
is created which internally creates and returns a Statement object. A reference to Statement
object is added to the NetStatement object and reference to NetStatement (MaterialStatement)
is added to the Statement object. Only when a Statement close() is called, the corresponding
MaterialStatement is closed and its reference to Statement object gets removed. 

Since MaterialStatement is an interface, can Net*Statement classes implement this interface
and also extend the Statement class? Is there any known reason for not doing this? I am working
on changes for this. I just wanted to know if I should pursue this or stick to the original
solution which seems to work. I would appreciate any suggestions for this. Thanks.

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