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] Commented: (DERBY-3324) JDBC statement cache implementation
Date Mon, 28 Jan 2008 13:31:38 GMT

    [ https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563141#action_12563141

Knut Anders Hatlen commented on DERBY-3324:

Thanks for the new patch, Kristian. It looks good to me.

> I'm still using an IAE, and the message is not localized. However, getting a null for
> 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.

Perhaps an assert would do? Then localization wouldn't be an issue. And we would still see
the resulting NPEs in insane mode, so no internal error would go unnoticed because of the
change. You wouldn't be able to keep the negative unit tests that behave identically in sane/insane
builds, though.

Tiny nit:

+    public boolean equals(Object obj) {
+        if (obj == null || !(obj instanceof StatementKey)) {
+            return false;
+        }

(obj instanceof StatementKey) implies (obj != null), so the null check is redundant.

> 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:
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>             Fix For:
>         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,
> 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
> 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.

View raw message