db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "John H. Embretsen (JIRA)" <derby-...@db.apache.org>
Subject [jira] Updated: (DERBY-210) Network Server will leak prepared statements if not explicitly closed by the user until the connection is closed
Date Fri, 03 Mar 2006 17:06:43 GMT
     [ http://issues.apache.org/jira/browse/DERBY-210?page=all ]

John H. Embretsen updated DERBY-210:

    Attachment: StatementStress.java

Uploaded my repro (StatementStress.java) for this issue.

The repro is an independent Java program with elements inspired by some of the "naughtiest"
parts of the infamous DOTS test case ATCJ2.java (see my previous comments to this issue).

I have tried to incorporate lots of explicit comments in the code, so that I will not get
bashed for not re-using or closing all PreparedStatements ;)

See main-method comments for usage instructions.

In short, the program does the following:


* Connects to a database, "naughtyWombat"
* Creates a table with two columns:
* Inserts 10000 rows into this table (in a sane fashion, I hope)
    * The ID column consists of the text "ITEM-X", where X is a number between 1 and 10000.
    * The DESCR column is always "This is a dummy description"
* Queries this table (by primary key) by:
    * Preparing a PreparedStatement (not using "?" placeholders, to stress the system)
    * Executing the query, and iterating through the result set
    * Closing the result set explicitly
    * Setting the PreparedStatement to null, without closing it explicitly first
With Derby in Client/Server mode and a server JVM heap size of 128 MB and PermGen size of
64 MB (this is pretty close to the defaults on modern JVMs and desktop/server machines), I
got the following results:

* With Derby trunk at SVN 382319, with Sun JDK 1.5, the server is disabled by an OutOfMemoryError
(PermGenSpace) after executing approximately 11000 query statements.
* With Derby trunk + derby-210-patch5-v1.diff (Sun JDK1.5), I have executed more than 900000
queries without any errors (the JVM is stressed, but is able to GC generated classes).
* I have also run the test against Derby in embedded mode, without seeing any errors.
* The test did not pass with jdk1.4.2, but I have not had time to test much or investigate
(I would appreciate if someone else could try this as well).

There is one important thing to be aware of, though:

It seems to me that it is not possible to eliminate this problem when the server is running
on a 1.3 JVM! 
This is because classes are not unloaded from the permanent generation with 1.3.x JVMs (as
far as I know).

Feel free to experiment with this code and/or adding some version of it as a regression test,
if appropriate...

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