db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@debrunners.com>
Subject Re: Unified DataSource API
Date Tue, 10 May 2005 23:32:02 GMT
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