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 Derby data sources
Date Thu, 27 May 2010 11:21:24 GMT
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,
-- 
Kristian




Mime
View raw message