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-3325) Add 'maxStatements' property to ClientConnectionPoolDataSource
Date Thu, 24 Jan 2008 13:23:34 GMT

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

Kristian Waagan commented on DERBY-3325:

Good points, Dan.

The non-localized message(s) is an oversight from my side. Thanks for reminding me. If you
see a trend, maybe we should try to raise the awareness about it in the community?
I thought about adding it to http://wiki.apache.org/db-derby/DerbyContributorChecklist , but
came to the conclusion it will clutter the list. My opinion is that this list should be short
and only include the most important issues. Is there another wiki document we can add it to?

I see one issue with the existing framework, and that is how we handle non-SQL exception messages
(or methods that can't throw Sql-/SQLException)?
Shall we just put them into SQLState/messages as usual, and use MessageUtil directly to obtain
the localized text? Or generate a SQLException to obtain the text?
What about severity codes? What states can be used for such messages?

What I meant about avoiding casts in the factory methods, is that all methods taking a data
source take ClientBaseDataSource. If I didn't add getMaxStatements into CBDS, I would have
to start checking if I could cast to CPDS or XADS to get the value of the maxStatements property.
Instead of the current approach, one could change the method signatures and possibly introduce
another data source class/interface. After incorporating Knut Anders' suggestion, I'm quite
happy about the current situation though.

Thanks bringing my attention to the issue, which can be a bit tricky I believe.
A few questions off the top of my head:
 a) What's the state of the existing data sources?
    Seems all of them are relying on the standard mechanism, but do provide an UID.
 b) What are the compatibility requirements?
 c) Should we enforce invariants on deserialization?
    An example is making sure maxStatements >= 0.

I have updated the overview attached to DERBY-3313, stating statement pooling for XA has lower
priority. However, it might come almost for free. If I run out of time, it will not be supported.
Note that CXADS does not inherit from CCPDS, so the maxStatements property will have to be
added there as well with the current hierarchy.

Based on further feedback and my own investigations, I might decide to add one or more subtasks
to the parent issue to handle the issues brought up by Dan's comments. There will be a new
patch anyway, to address the comments from Knut Anders (and possibly those from Dan).


> Add 'maxStatements' property to ClientConnectionPoolDataSource
> --------------------------------------------------------------
>                 Key: DERBY-3325
>                 URL: https://issues.apache.org/jira/browse/DERBY-3325
>             Project: Derby
>          Issue Type: Sub-task
>          Components: JDBC, Network Client
>    Affects Versions:
>            Reporter: Kristian Waagan
>            Assignee: Kristian Waagan
>            Priority: Minor
>             Fix For:
>         Attachments: derby-3325-1a-maxStatements.diff, derby-3325-1a-maxStatements.stat
> The classes in Derby implementing javax.sql.ConnectionPoolDataSource must provide setter
and getter methods for the property 'maxStatements'.
> This property is used to control the whether the data source should produce pooled connections
with statement cache capabilities or not, and how big the statement cache is allowed to be.
> This issue only deals with the client JDBC driver.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message