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 Wed, 11 May 2005 18:44:00 GMT
Jeremy Boynes wrote:

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

With your proposal when a JDBC URL request comes a DataSource (like)
object is required to obtain the connection, either:

 - the object is created and filled in on the fly - possible extra
overhead, though maybe the existing properties object is similar
overhead today.

 - a object already exists with the correct properties - management
would be needed for these objects

I think the implementation of how the connection is obtained under the
covers could be separated from the issue of how many DataSource objects
exist for Derby. Today it carries the state in properties object and
possibly could be improved under the covers to use a DataSouce model.
But we define the user visible DataSource model separately.

View raw message