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
agree
* use of Properties, again providing no type safety
agee
* 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
Regards Lance
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
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?)ReferenceableDataSource
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
