Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (asf.osuosl.org: domain of olavsa@gmail.com designates
 64.233.162.199 as permitted sender)
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws;
        s=beta; d=gmail.com;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=MAouhtu4sKyNc7mGuVjyTOl8wp6qOVsQM766l9IqaDRJD7wKn6PZbQWdDrn3p8CLesXRvwP+vUXs9k2h0Ib8ifEe9LrRD+l3OO5/CuXgStF2aXvv46K9VWtkPcWrF9nY4lM14NigLhmfen77Phru0pp0Cay/i1kfSC1tbKapteM=
Message-ID: <d4ea1e910606200956h28d445d4ob550166ab199a86a@mail.gmail.com>
Date: Tue, 20 Jun 2006 18:56:12 +0200
From: "=?ISO-8859-1?Q?Olav_Sandst=E5?=" <olavsa@gmail.com>
To: derby-dev@db.apache.org
Subject: Re: Driver autoloading and engine booting
In-Reply-To: <44933535.8050801@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <44933535.8050801@sun.com>

On 6/17/06, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> It is probably worthwhile documenting this Heisenbug somewhere in our
> user guides and release notes. In addition, two solutions have been
> proposed for eliminating the extra exposure introduced by JDBC4. Neither
> of these approaches addresses the pre-JDBC4 case:
>
> 1) Remove the JDBC4-driver-autoloading. This removes a useful
> ease-of-development feature and makes us fail to be JDBC4-compliant.
>
> 2) Don't boot the engine when registering the embedded driver. Instead,
> boot the engine the first time that someone requests an embedded
> Connection. This approach involves a lot of testing.
>
> In addition, we could
>
> 3) Decide that the extra exposure is minimal and not do anything besides
> document it.

My opinion is:

-Alternative 2 will be the best given that we want to support
autoloading (and that we want to be JDBC4 compliant - which I think is
a good idea)

-To remove autoloading would also been a way to go if we still could
claim to be JDBC4 compliant. I do not see autoloading as a very
valuable "ease-of-development" feature as it is now - it basically
eliminates one line of code. And it removes the control from the
application program of when the driver is loaded and restrict the way
programs using Derby (and other JDBC driver) needs to be written to
take this into account. I would have prefered that autoloading worked
more along "load the driver when it is needed - when the application
first request it normally when the first getConnection is called"
instead of "load every JDBC4 complient driver that the class loader is
able to find" - it should have been possible to implement it this way
too.

On a side note, the road map for autoloading might look like this:

 -JDBC5: the DriverManger will in addition to load the driver also
automatically create a connection to the database - if unable to get a
connection, attempt to start the database server....

-JDBC6: the DriverManager will use Google to search for all JDBC6
compliant driver and download and autoload all it can find ....

...just to make it easy for the developers :-)

Regards,
Olav