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 20:55:11 GMT
Jeremy Boynes wrote:

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

I was only talking about getting a connection via a JDBC URL.
> 
>>  - 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 wasn't talking about that DataSource, but a possible optimisation
where a Java Bean (as you call it, I was using 'DataSource (like)' :-)
could be pre-populated for the common connection requests, to avoid
having to create a new Java Bean object each time. With such a scheme
there would need to be management of those objects. Probably not worth
it, but I wasn't exactly sure what you were proposing in this area, but
your comments above clear that up.

Dan.


Mime
View raw message