[jira] [Commented] (DERBY-2380) A statement plan holds onto resources such as its generated class even after it has been invalidated.

["ASF subversion and git services (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/DERBY-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13896595#comment-13896595 ] 

ASF subversion and git services commented on DERBY-2380:
--------------------------------------------------------

Commit 1566635 from [~knutanders] in branch 'code/trunk'
[ https://svn.apache.org/r1566635 ]

DERBY-2380: Make the generated class eligible for gc once the statement is invalidated

> 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
>              Labels: derby_triage10_5_2
>         Attachments: d2380-clear-activation-class.diff
>
>
> 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 was sent by Atlassian JIRA
(v6.1.5#6160)