[
https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristian Waagan updated DERBY-3324:
-----------------------------------
Attachment: derby-3324-1c-jdbc_statementcache.stat
derby-3324-1c-jdbc_statementcache.diff
'derby-3324-1c-jdbc_statementcache.diff' replaces revision 1b and contains the
following changes:
* Merged all key classes/interfaces into one class.
This looks a lot simpler! Thanks for the suggestion Knut Anders.
* Added some SanityManager.DEBUG blocks with asserts in JDBCStatementCache.
If nulls are received, it indicates a programming error, but Derby
should/will not fail.
In an insane build, the worst effect will be a NPE somewhere else or that a
statement
that could have been cached will be thrown away and prepared again the next
time.
* Added a test case.
* Minor tweaks to the documentation.
I'm still using an IAE, and the message is not localized. However, getting a
null for the
compilation schema or the SQL query string suggests a programming error and
should
be caught before a release is produced, or handled before it gets this far in
the code.
Patch ready for review.
> JDBC statement cache implementation
> -----------------------------------
>
> Key: DERBY-3324
> URL: https://issues.apache.org/jira/browse/DERBY-3324
> Project: Derby
> Issue Type: Sub-task
> Components: Network Client
> Affects Versions: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.4.0.0
>
> Attachments: derby-3324-1a-jdbc_statementcache.diff,
> derby-3324-1a-jdbc_statementcache.stat,
> derby-3324-1b-jdbc_statementcache.diff,
> derby-3324-1b-jdbc_statementcache.stat,
> derby-3324-1c-jdbc_statementcache.diff, derby-3324-1c-jdbc_statementcache.stat
>
>
> Implement a cache for storing JDBC prepared statement objects.
> The cache will be responsible for holding free prepared statement objects
> that can be reused, and also to throw away objects if the cache grows too big.
> All objects in the cache must belong to the same physical connection, but
> they can be reused across logical connections obtained from a single physical
> connection in a connection pool.
> This component is probably a candidate for code sharing between the client
> and the embedded driver. Sharing will not be part of this issue.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
