[
https://issues.apache.org/jira/browse/DERBY-7006?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16647919#comment-16647919
]
Rick Hillegas commented on DERBY-7006:
--------------------------------------
Here is another issue with solution S2:
Every prepared statement has its own ClassLoader (an instance of
ReflectJavaLoader2). That ReflectJavaLoader2 loads the prepared statement's
generated class. This lets Derby garbage-collect the generated class along with
the prepared statement when the prepared statement is evicted from the
statement cache.
Under solution S2, the generated module is bound to the statement-specific
ReflectJavaLoader2. That is why solution S2 generates one module per prepared
statement. I do not see how to improve solution S2 in order to support both of
the following requirements:
1) generate a single module per database
2) continue to support the garbage-collection of statements when they are
evicted from the statement cache.
> Investigate putting generated classes under the engine module loader
> --------------------------------------------------------------------
>
> Key: DERBY-7006
> URL: https://issues.apache.org/jira/browse/DERBY-7006
> Project: Derby
> Issue Type: Improvement
> Components: SQL
> Affects Versions: 10.15.0.0
> Reporter: Rick Hillegas
> Priority: Major
> Attachments: derby-7006-01-aa-remiForax.diff,
> derby-7006-01-ac-alanBateman.diff
>
>
> Right now, the generated query plans are compiled into the catch-all unnamed
> module. This forces us to grant reflective access to several engine packages.
> It would be nice to encapsulate the generated classes inside the engine
> module loader.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
