db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Daniel John Debrunner (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1142) Metadata calls leak memory
Date Tue, 11 Jul 2006 22:47:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1142?page=comments#action_12420461 ] 

Daniel John Debrunner commented on DERBY-1142:

Two patches applied (420656 & 421015) that stop the memory leak shown in the repro.

A leak still exists if the repro is modified to not close the ResultSet.
This is because the activations marked unused in the language connection context are only
cleaned up if a commit or rollback is executed.
In this code no such call is made.

One solution is to look for unused activations when an activation is added to GenericLanguageConnectionContext
(addActivation method).
A couple of possible solutions to avoid overhead when no check is needed are:
           - Have Activation.markUnused() set an boolean (unsynchronized) flag in the LCC
to indicate it has some unused activations
           -  Only perform the check if the number of activations is beyond some threshold.

Not sure how urgent it is needed to solve this issue, if the application calls commit or rollback
in any way (as most applications will at some point)
then memory leak will not be seen. This repro is an extereme edge case.

> Metadata calls leak memory
> --------------------------
>          Key: DERBY-1142
>          URL: http://issues.apache.org/jira/browse/DERBY-1142
>      Project: Derby
>         Type: Bug

>   Components: JDBC
>     Versions:,
>     Reporter: Knut Anders Hatlen
>     Assignee: Daniel John Debrunner
>     Priority: Minor
>  Attachments: 1142_close_single_use_activations_draft.txt, 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:
For more information on JIRA, see:

View raw message