[jira] Commented: (DERBY-1142) Metadata calls leak memory

["Anders Morken (JIRA)" <de...@db.apache.org>]

    [ http://issues.apache.org/jira/browse/DERBY-1142?page=comments#action_12371561 ] 

Anders Morken commented on DERBY-1142:
--------------------------------------

The direct cause of the memory usage is in the org.apache.derby.impl.sql.conn.GenericLanguageConnectionContext class, more specifically its member "acts", which is a Vector of Activation instances. It seems one Activation is added to the vector for every dmd.getSchemas() execution, but they are never removed. I've drilled down to this using NetBeans' memory profiler and debugger and IBMs HeapRoots utility in concert. While I can hunt through heap dumps I can't say that I know enough about Derby internals yet to suggest how to fix this. I've tried explicitly closing the preparedstatement in DatabaseMetaData before returning, but to no effect. I need some time to figure out how all these things (activations, prepared statements, connections and connection contexts) fit together. =)

> Metadata calls leak memory
> --------------------------
>
>          Key: DERBY-1142
>          URL: http://issues.apache.org/jira/browse/DERBY-1142
>      Project: Derby
>         Type: Bug
>   Components: JDBC
>     Versions: 10.2.0.0, 10.1.2.1
>     Reporter: Knut Anders Hatlen
>     Priority: Minor
>  Attachments: metadataloop.java
>
> When calling a DatabaseMetaData method that returns a ResultSet,
> memory is leaked. A loop like this (using the embedded driver)
>   while (true) {
>     ResultSet rs = dmd.getSchemas();
>     rs.close();
>   }
> will eventually cause an OutOfMemoryError.

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