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.
