db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <rick.hille...@oracle.com>
Subject Re: Derby data sources
Date Fri, 28 May 2010 14:03:24 GMT
Hi Kristian,

Thanks for your detailed explanation of this bizarre and confusing 
behavior. I can imagine that this inconsistency is very frustrating to 
our users.

Each of the options you are considering will create backward 
compatibility problems for some applications. I agree with Knut that 
silent behavior changes are worse than noisy ones. I think that we could 
talk ourselves into an incompatible behavior change if the javadoc 
explicitly says that the behavior is undefined.

However, I don't see much value in moving from one inconsistent behavior 
to another. If we want to tackle this confusion, then I would recommend 
that we define the behavior explicitly in the javadoc and make all of 
the DataSources conform to the defined behavior.

So my advice would be to not touch the code yet. Instead, file a JIRA 
based on your detailed explanation of the problem. Then let the 
community discuss what the best solution is.

Thanks,
-Rick



Kristian Waagan wrote:
> 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,


Mime
View raw message