[
https://issues.apache.org/jira/browse/DERBY-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476806
]
Daniel John Debrunner commented on DERBY-2380:
----------------------------------------------
First, some cleanup is needed for stored prepared statements (which are used
for JDBC meta-data queries and triggers).
ExecSPSNode has this code (generate)
/*
** The following does a prepare on the underlying
** statement if necessary. The returned statement
** is valid and its class is loaded up.
*/
ps = spsd.getPreparedStatement();
However the returned statement is "partially valid", it's isValid field is set
to false because SPSDescriptor performed a makeInvalid() on it when it compiles
the stored plan the first time. SPSDescriptor then holds onto this "partially
valid" to provide the compiled information for the real running of the
statement through the internal EXECUTE STATEMENT command. Applying the obvious
fix for this bug, nulling out the compiled information, then leaves the
prepared statement used by SPS in a fully invalid state, causing
NullPointerExceptions as all the compiled information has been removed.
Having a "partially valid" state is not a good design, it complicates the
already hard to understand SPS code. Will be looking at ways to avoid this so
that a makeInvalid() on a language prepared statement (plan) can always make
the object invalid.
> 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.0.0
> Reporter: Daniel John Debrunner
> Assigned To: 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.
