Rick Hillegas wrote:
> Three months ago, we shelved this topic, promising to return to it
> later. I would like to reach consensus on this problem now. In a
> nutshell: JDBC4 introduces new methods whose signatures contain
> generics. Because of this, DataSource implementations can't satisfy both
> the JDBC3 and JDBC4 contracts. I would like to restart the discussion by
> proposing the following:
>
> 1) Derby's public API will contain two sets of DataSource
> implementations, one which satisfies the JDBC3 contract and one which
> satisfies JDBC4.
>
> 2) The documented, approved way to obtain DataSources will be to call
> factory methods on EmbeddedDriver and ClientDriver. These factory
> methods will hand back either JDBC3 or JDBC4 DataSources depending on
> the vm.
How does this work in app server environments where you simply specify
the DataSource class name directly in the settings for a connection
pool? Do I as someone deploying into an app server have to choose which
Derby DataSource to use?
Also, you have described the public API. Am I to assume that internally
the JDBC 4 DataSource will somehow be able to take advantage of the
inheritance framework that currently exists today?
It also seems a little odd to have EmbeddedDriver/ClientDriver be a
factory for DataSource which then uses EmbeddedDriver/ClientDriver to
manufacture connections... I guess it's OK, but I worry about circular
dependencies...
Will there also be separate XADataSource and ConnectionPoolDataSource
implementations for JDBC3-- and JDBC4++?
David
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
