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 Wed, 11 May 2005 13:30:16 GMT

Jeremy Boynes wrote:

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

  If you are using J2SE 6, you can make this mechanism work with any 
JDBC driver  if you follow the changes needed to make the service 
provider mechanism

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


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

The use DataSource from J2SE without JNDI,  just never caught on at 
least as of now.  Even do the docs state this is the preferred 
mechanism, the reality is that it is not used widely outside of  the 
container world right now

We had looked at the possibilities of trying to do further improvements 
in this area for JDBC 4, but due to the time contraints of  the J2SE 6 
schedule, had to remove this item.

If you have suggestions, I would love to hear them as I am working on a 
list of items for JDBC.next.

Please drop me a note off line Jeremy and we can discuss this further


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

View raw message