db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: Derby data sources
Date Mon, 28 Jun 2010 13:18:54 GMT
On 28.05.10 16:03, Rick Hillegas wrote:
> 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.

Hi Rick,

Finally took the time to create a Jira for this :)
See DERBY-4719 [1].


[1] https://issues.apache.org/jira/browse/DERBY-4719

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

View raw message