db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-3324) JDBC statement cache implementation
Date Thu, 24 Jan 2008 11:19:34 GMT

    [ 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

- 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

- 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.


> 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
> 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