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


Mime
View raw message