[
https://issues.apache.org/jira/browse/DERBY-2380?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12476933
]
Daniel John Debrunner commented on DERBY-2380:
----------------------------------------------
A GenericPreparedStatement instance can used in various situations and the
resuling handling of its state in these situations is awkward.
The various situations are in the statement cache and unused, in the cache and
in use, referenced in a JDBC prepared statement with an activation, attached to
an SPSDescriptor without an activation, in-use in a trigger.
The state handling involves a use-count (for existing activations), the check
to see if the plan is being cache and the "partially valid" state for the SPS
mentioned in the previous comment.
Ideally just having a reference to a GenericPreparedStatement would keep it
valid.
Looking at ways to clean this up it seems that the root cause is the
DependencyManager. The DependencyManager is implementing the Observer pattern
but in a non-java way.
http://www.research.umbc.edu/~tarr/dp/lectures/Observer.pdf
Since the GenericPreparedStatement instance is held onto in a central
DependencyManager object, then some state is needed as to when it should be
removed from that list,handling dependencies the "java way" would instead mean
the list of dependents is held in the object itself, not a central list.
Now the Java Observable class has some issues, but I wonder if the pattern
should be applied here. Persistent dependencies cause some issues but I just
wanted to throw my thoughts out there.
> 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.
