db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Unified DataSource API
Date Wed, 11 May 2005 01:31:59 GMT
Lance J. Andersen wrote:
> 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 
> Class.forName(com.acme.FooDriver).
> There is no need for a J2EE application to utilize anything but a 
> DataSource IMHO.

Agreed - especially as JNDI is required and the application should be 
obtaining the DataSource from java:comp/env or in J2EE 5 via injection.

There is still the J2SE environment. Originally Driver was the only 
mechanism available and of course we still need to support it. However, 
there are some issues with how they are configured:

* the need to instantiate the implementation so that it can register
   with the DriverManager.

* the embedding of properties in the URL string providing no type

* use of Properties, again providing no type safety

* a rather quirky API for getting property info from the Driver

With the JDBC 2.0 extension and 3.0, DataSource became available as the 
preferred mechanism. Ideally this would be via JNDI lookup (although 
there is no standard provider and/or location for the binding in J2SE), 
but as an alternative configuration can now be done using standard 
JavaBean semantics (e.g. hard coding get/set calls, serialization (.ser 
file), XML storage, reflection in conjunction with PropertyEditors, 
etc.) This provides much more flexibility than specialized Driver code.

> Daniel John Debrunner wrote:
>> 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
>> connection.

The current model offers different combinations of properties depending 
on the implementation class selected. The user must select the right 
class for the type of connection they are using.

The unified model allows the user to configure the properties as they 
need and rely on the implementation to select the type of connection 
appropriate based on the values they configure.

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

I don't agree that it is incorrect - as described above I think the use 
of JavaBean semantics makes end-user configuration easier.

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

DataSources are configured as outbound J2CA Connectors with the property 
values initialized as ManagedConnectionFactory properties - basically 
JavaBean configuration.

One connector we have wraps a generic JDBC Driver so they can be 
configured that way. We also have ones that wrap vendor specific 
implementations, mapping MCF properties to DataSource properties.

The app server always binds its own implementation of DataSource into 
JNDI - this is typical and is as described in the JDBC spec. That 
implementation delegates to the ConnectionManager that deals with 
pooling and handle/component dis/re-association.

>> So we end up with three data source implementations anyway :-)
>> EmbeddedDataSource - existing api
and deprecated

>> DerbyDataSource
the one used by applications

>> ReferenceableDataSource
used where you have a J2SE environment using JNDI (which seems atypical 
even though the spec says that is the preferred method; if not would 
this not be handled by the appserver vendors rather than end users?)

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

Well today there are two - one for the client and one for embedded.

The state is there in both cases. In the current case it is held in the 
URL/properties which is easy for the Driver impl but means the 
DataSource impl is doing value->String conversion; the URL String and 
properties are then parsed/validated by the factory.

In the unified case it is held in a JavaBean which can be passed 
directly to the factory (no parsing). The Driver impl still needs to 
parse the URL/properties but there is no added overhead here.

I don't see where state management comes in.


View raw message