db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lance J. Andersen" <Lance.Ander...@Sun.COM>
Subject Re: Unified DataSource API
Date Tue, 10 May 2005 23:44:25 GMT
The reality is that there are way too many applications which utilize 
java.sql.Driver implementations to depecrate this functionality.

We are in JDBC 4 reducing the boiler plate code  by having 
DriverManager.getConnection() utilize the Server Provider Mechanism in 
J2SE to load the driver, removing the need for 

There is no need for a J2EE application to utilize anything but a 
DataSource IMHO.


Daniel John Debrunner wrote:

>Jeremy Boynes wrote:
>>The main changes are:
>>* DerbyDataSource is the implementation expected to be used by end
>>  user applications (both J2SE and J2ME). This implements the basic
>>  DataSource API returning a single physical connection.
>Should we be encouraging J2SE/J2EE applications to use a DataSource
>*implementation*? JDBC 3.0 spec states:
><section 9.4.1>
>"DataSource properties are not intended to be directly accessible by
>JDBC clients. This design is reinforced by defining the access methods
>on the implementation class rather than on the public DataSource
>interface used by applications. Furthermore, the object that the client
>manipulates can be a wrapper that only implements the DataSource
>interface. The setter and getter methods for the properties need not be
>exposed to the client."
>Thus applications are only meant to deal with the javax.sql.DataSource
>and the JNDI lookup already provides database location independence.
>I believe J2SE applications are still intended to use the DriverManager
>interface and indeed the JDBC 4.0 expert group is improving the
>functionality of registering drivers using the driver manager, not
>deprecating it.
>Now JSR 169 for J2ME breaks the intent of section 9.4.1 and I complained
>about that to the JSR 169 expert group. I'm the reason that the examples
>in the JSR 169 DataSource javadoc are correct and show that reflection
>has to be used. [They used to show vendor specific setXXX methods being
>called on the javax.sql.DataSource interface].
>I'm not against a change like this, but I do want to understand how this
>improves anything, especially given how DataSource objects are meant to
>be used. One of the uses is for tools to use reflection to query the
>properties and provide gui access to them
><section 9.4.1>
>"Management tools that need to manipulate the properties of a DataSource
>implementation can access those properties using introspection."
>The current model means that the set of properties are all completely
>valid for a Derby datasource. Your proposed model changes that so that
>the valid set of properties is a subset based upon the value of one
>property ("network protocol"). How does that affect introspection tools,
>does it make them easier or harder for the user? E.g. a generic tool
>will still display "port" and "serverName" if I select an embedded
>So I guess I see your proposal only described in terms of a usage model
>that I believe is incorrect, namely application's direct use of Derby's
>DataSource implementations.
>As a matter of interest, how does Geronimo re-create (store) a DataSource?
>    - from a serialized object
>    - from a class name and a set of properties [key/value pairs] (e.g.
>in a config file)
>    - using Referencable
>>* ReferenceableDataSource is now a subclass rather than a base class.
>>  The reasoning is that it would only be used to bind data sources
>>  into a JNDI server that did not support Java Objects; this is a
>>  fairly specialized usecase. The only reason this is separate is
>>  because J2ME CDC/FP 1.0 does not support javax.naming.
>So we end up with three data source implementations anyway :-)
>EmbeddedDataSource - existing api
>I would have loved to not have the special J2ME data source, and instead
>have EmbeddedDataSource work for both, but the fact that
>EmbeddedDataSource already implemented Referenceable meant I didn't want
>to change it to avoid backwards compatibility issues.
>>* The intention is to use the same API for both client and server
>>  connections. The ConnectionFactory would create the appropriate
>>  Connection implementation depending on the properties in the
>>  DataSource. For example, if the networkProtocol is specified as
>>  "drda" and/or the serverName is non-null then a client connection
>>  would be created; if the protocol is "embedded" and/or serverName
>>  is null then we would create an embedded server. This makes the
>>  application code unaware of the physical location of the database.
>>  Yes, more concrete definition is needed for the semantics here.
>>* The Driver implementation now uses the DataSource implementation
>>  (without using the actual interface so we can continue to support
>>  JDBC 2.0 core) rather than the other way around. This seemed like
>>  a natural refactoring given the approach adopted by JSR169.
>At the bottom level you need some generic interface that hands a
>connection back, today it is based upon the stateless
>DriverManager/Driver model, with the connection being completely defined
>by a JDBC URL and a set of properties.
>Not sure of the advantage to move to a DataSource model, because the
>DataSource model has state, the set of properties. So what state is
>required and how are these stateful objects managed?

View raw message