Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Message-ID: <593277618.1246911194954.JavaMail.jira@brutus>
Date: Mon, 6 Jul 2009 13:13:14 -0700 (PDT)
From: "Rick Hillegas (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Subject: [jira] Assigned: (DERBY-2380) A statement plan holds onto resources
 such as its generated class even after it has been invalidated.
In-Reply-To: <12911039.1172697770825.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


     [ https://issues.apache.org/jira/browse/DERBY-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Rick Hillegas reassigned DERBY-2380:
------------------------------------

    Assignee:     (was: Daniel John Debrunner)

Unassigning this issue since there has been no activity in more than a year.

> A statement plan holds onto resources such as its generated class even after it has been invalidated.
> -----------------------------------------------------------------------------------------------------
>
>                 Key: DERBY-2380
>                 URL: https://issues.apache.org/jira/browse/DERBY-2380
>             Project: Derby
>          Issue Type: Bug
>          Components: SQL
>    Affects Versions: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.2.2.0, 10.3.1.4
>            Reporter: Daniel John Debrunner
>
> An internal plan (instance of GenericPreparedStatement) can be invalidated by other SQL operations such as DROP TABLE or DROP INDEX.
> When this happens the references to objects that are no longer useful such as the generated class and saved objects are held onto and thus use memory.
> If the statement is re-compiled then these objects will be handled by garbage collection.
> If the statement is not recompiled though, then these objects will remain until the plan (GenericPreparedStatement) is garbage collected.
> The plan being garbage collected can be held up for two reasons:
>    1) The plan is in the statement cache. Note that only in some cases does it make sense to remove an invalid plan from the statement cache, e.g. a DROP TABLE should remove any plan that uses that table, but a DROP TRIGGER should not remove an INSERT from the cache, as it is likely the plan will be re-used and re-compiled. This  is a separate issue given that the memory usage can occur even if the plan is not in the cache.
>    2) The application holds onto a JDBC PreparedStatement that uses the plan.
> Given an application should not be able to affect memory usage like this then the GenericPreparedStatement.makeInvalid() call should null out fields that hold references to objects that have become invalid.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.