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-4719) Define consistent Derby data source behavior
Date Tue, 29 Jun 2010 17:30:49 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12883620#action_12883620
] 

Kristian Waagan commented on DERBY-4719:
----------------------------------------

Hi again Rick,

i') I think that's the pattern being followed, but note that there may be explicit setters
for attributes that cannot be controlled by the connection attribute string (for instance
setMaxStatements to control the client side JDBC statement caching). This may very well be
an oversight, and yet another thing we can settle when we know how we want things.

ii') Yes, hopefully by refactoring and reusing code in the driver (I haven't looked into this).

iii') I haven't yet convinced myself which mechanism should have precedence (setter or attribute
string), i.e. what the users want and why.
The situation for the GUIs I was thinking about will be the same as for the XML case, so letting
one trump the other regardless of order is fine. In the GUI you can see the list of "bean
properties", for instance "traceLevel" (which will be mapped to "setTraceLevel") and "connectionAttributes"
(mapped to "setConnectionAttributes").


Regarding DERBY-4067, it will only make ClientConnectionPoolDataSource and ClientXADataSource
parse the connection attribute string. Then all three client data sources will behave identical.
Wrt precedence, whatever is in the connection attribute string when the connection is initiated
(getConnection, getPooledConnection or getXAConnection) will take effect. I'd prefer creating
a new Jira for changing that, since some tests have been disabled due to DERBY-4067 (there
is also a duplicate issue logged for traceFile specifically) and it would be nice to get it
fixed soon.
That fix can also be backported I guess, but we should probably not change the precedence
rules for already released versions.

> Define consistent Derby data source behavior
> --------------------------------------------
>
>                 Key: DERBY-4719
>                 URL: https://issues.apache.org/jira/browse/DERBY-4719
>             Project: Derby
>          Issue Type: Task
>          Components: Documentation, Javadoc, JDBC, Network Client
>    Affects Versions: 10.7.0.0
>            Reporter: Kristian Waagan
>
> The behavior of the various data source implementations in Derby isn't consistent.
> As a starting point, from the thread [1] on derby-dev:
> -----
> Hi,
> I have been investigating how the various Derby data source implementations behave when
it comes to [bean] properties.
> Properties and attributes are used interchangeably, and I'll be using the following abbreviations:
>  o DS-[E|C] the "normal" data souce embedded/client
>  o CP-[E|C] ConnectionPoolDataSource embedded/client
>  o XA-[E|C] XADataSource embedded/client
> Here are some of the current issues:
>  1) CP-C and XA-C effectively ignore the connection attribute string for certain attributes
(those who have individual setters, DERBY-4067)
>  2) *-E don't update the internal property state based on the connection attribute string
(i.e. specifying ";user=myuser" won't change the return value of getUser() after connect).
>  3) Only some of the properties are updated from the connection attribute string. This
is as expected, but it is confusing that for instance 'traceDirectory' is updated and 'traceLevel'
isn't.
>  4) *-C has 'APP' as the default user, *-E has <null>.
>  5) Some property setters accept all values, others throw an exception if the value is
invalid.
> I don't think all these issues should be fixed, but I'd like to fix (1), as it has caused
some trouble in the past (i.e., user not understanding why the settings aren't taking effect).
> There are several possible fixes for (1):
>  1a) Make CP-C and XA-C process the connection attribute string to update the internal
state.
>  1b) Make DS-C ignore the connection attribute string (may break existing deployments).
>  1c) Throw exception if a property with a setter is specified in the connection attribute
string.
> I don't care that much about which solution is chosen, but I'd prefer that the various
data sources are consistent. For instance, it would be nice if a user could swap ClientDataSource
with ClientConnectionPoolDataSource without having to change the data source definition. For
instance, doing this today with "ssl=basic" in the connection attribute string would make
DS-C connect with SSL, but CP-C would connection without SSL.
> We have this wording in the JavaDoc for ClienBaseDataSource.setConnectionAttributes(String):
> "Set this property to pass in more Derby specific connection URL attributes.
> Any attributes that can be set using a property of this DataSource implementation (e.g
user, password) should not be set in connectionAttributes. Conflicting settings in connectionAttributes
and properties of the DataSource will lead to unexpected behaviour."
> Any opinions or questions on any of this?
> Regards, 
> -----
> [1] http://old.nabble.com/Derby-data-sources-to28692616.html#a28692616

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