[
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).
thanks,
> 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: 10.4.0.0
> Reporter: Kristian Waagan
> Assignee: Kristian Waagan
> Priority: Minor
> Fix For: 10.4.0.0
>
> 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.
