[ http://issues.apache.org/jira/browse/DERBY-210?page=all ]
Deepa Remesh updated DERBY-210:
-------------------------------
Attachment: derby-210.diff
derby-210.status
I am uploading a combined patch 'derby-210.diff' which solves the memory leak.
As Bryan suggested, I am uploading this patch and will open jira issues for
other optimizations. Patch does the following:
* Eliminates the below references to PreparedStatement objects by using
WeakHashMap instead of LinkedList. When there are no other references to the
keys in a WeakHashMap, they will get removed from the map and can thus get
garbage-collected. They do not have to wait till the Connection object is
collected.
- 'openStatements_' in org.apache.derby.client.am.Connection
- 'CommitAndRollbackListeners_' in org.apache.derby.client.am.Connection
* Removes the list 'RollbackOnlyListeners_' since this is not being used.
* Updates the following comment for openStatements_:
// Since DERBY prepared statements must be re-prepared after a commit,
// then we must traverse this list after a commit and notify statements
// that they are now in an un-prepared state.
final java.util.LinkedList openStatements_ = new java.util.LinkedList();
In the code, I did not see this list being traversed after a commit to
re-prepare statements. Also, I think this is not needed since Derby does not
require re-prepare of statements after a commit. Currently, this list is used
to close all open statements when the originating connection is closed.
* Removes all ResultSets from HashTable
'positionedUpdateCursorNameToResultSet_' in SectionManager. Only result sets of
positioned update statements were being removed from this hashtable whereas all
result sets were added. Because of this, client driver was holding on to result
sets and statements even after rs.close() was called.
* Adds a test 'derbyStress.java' to jdbcapi suite. This test is based on the
repro for this patch. Without this patch, it fails when run with client driver.
Kathey had suggested in another mail that tests for client memory leak problems
(DERBY-557, DERBY-210) can be added to same test. I did not see an existing
test. So I created this new test. If DERBY-557 does not have a test, I think it
can be added to this new test.
* Excludes the new test from running with jcc because jcc gives out of memory
error.
* Creates 'derbyStress_app.properties' with following property
'jvmflags=-Xmx64M' to guarantee the test fails on all machines.
Successfully ran derbyall with Sun JDK 1.4.2 on Windows XP. Please take a look
at this patch.
> 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: 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
