[
https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12563684#action_12563684
]
Kristian Waagan commented on DERBY-3324:
----------------------------------------
Yes it can.
I think I put holdability first because some methods only specify the
holdability, and I chose to keep the factory methods consistent. This was maybe
not such a good idea.
Another thing one could do (additionally), is to add asserts to enforce valid
values for the various properties. This would only affect sane builds though.
Is it worth adding, or too much checking?
I'll make a patch tomorrow.
> 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,
> derby-3324-1d-jdbc_statementcache.diff, derby-3324-1e-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 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.
