db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-2380) A statement plan holds onto resources such as its generated class even after it has been invalidated.
Date Fri, 07 Feb 2014 16:04:20 GMT

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

Knut Anders Hatlen updated DERBY-2380:
--------------------------------------

    Attachment: d2380-clear-activation-class.diff

One possible incremental improvement is to clear the activation class in GenericPreparedStatement
when the statement is invalidated. GenericStatement does this before repreparing a GPS, so
the code is already prepared to handle the case where the activation class is null.

The attached patch d2380-clear-activation-class.diff makes this change, and also refactors
the code so that it's shared between reprepare and invalidate.

All regression tests ran cleanly. I also hand-tested to see that the activation classes of
invalidated statements could be garbage collected immediately. Without the patch, one had
to wait until they had either been recompiled or evicted from the statement cache before they
could be garbage collected.

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

Mime
View raw message