[
https://issues.apache.org/jira/browse/DERBY-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12562014#action_12562014
]
Kristian Waagan commented on DERBY-3324:
----------------------------------------
Good feedback Knut Anders :)
Regarding the PreparedStatement vs CallableStatement issue, I think I'll
postpone it for now because I don't have much feeling for it.
Are there only advantages, or are there drawbacks as well?
I do feel that some flexibility is lost with your suggested approach for the
keys, but I will follow your advice because;
* affected classes are all internal and very contained, so it can be heavily
changed later without problems
* the extension room is rather small (the prepareStatement methods with int[]
and String[]).
* code readability does matter
* the KISS principle should be followed :)
I don't agree with the NPE vs IAE comment in this case, because I feel IAE
convey a little more information. However, there seems to be different opinions
about this. Some food for thought:
- IllegalArgumentException (JavaDoc): "Thrown to indicate that a method has
been passed an illegal or inappropriate argument."
- NullPointerException (JavaDoc): "Thrown when an application attempts to use
null in a case where an object is required. These include:
* Calling the instance method of a null object.
* Accessing or modifying the field of a null object.
* Taking the length of null as if it were an array.
* Accessing or modifying the slots of null as if it were an array.
* Throwing null as if it were a Throwable value.
Applications should throw instances of this class to indicate other illegal
uses of the null object."
- http://lists.ibiblio.org/pipermail/dev-dpml/2005q1/000658.html
Seems both can be used, and that there are alternative solutions. Is this
something we should discuss in the community to achieve consistency, or is it
just a less important matter of taste and style?
I will post a new patch when I have incorporated the changes.
Thanks
> 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
>
>
> 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.
