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.
This is what I am doing - the Driver implementation parses the URL/properties and constructs and initializes a JavaBean to hold them. This bean is passed to the connection factory which returns the Connection implementation.
In other words, what we've done is move the parsing code from the internal driver impl into the public driver impl.
When using a DataSource, it is already a JavaBean so can be passed down directly. This eliminates the parsing of the URL and String properties that is done today.
- a object already exists with the correct properties - management would be needed for these objects
That would not be our issue - the DataSource state is managed by the JNDI implementation or whatever else is storing the connection properties.
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.
These are two separate issues - I just rolled them both into the code to show how it could be done.
-- Jeremy
