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 20:09:14 GMT
Daniel John Debrunner wrote:
>>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.


View raw message