Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: neutral (asf.osuosl.org: local policy)
Message-ID: <447C66D2.8010202@apache.org>
Date: Tue, 30 May 2006 08:37:54 -0700
From: Daniel John Debrunner <djd@apache.org>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Autoloading of JDBC drivers considered harmful?
References: <44778871.4030006@sun.com>
In-Reply-To: <44778871.4030006@sun.com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Olav Sandstaa wrote:

> Hi,
> 
> Based on some of the findings with the Nist tests failing when running
> with JDK 1.6 due to autoloading of the embedded driver I am not sure if
> it is a good idea to support autoloading of the embedded Derby driver.
> 
> Consider the following example:
> 
> 1. Someone is having a small application that is using (for instance)
> the DB2 driver to connect to a Derby database. This application is
> running with JDK 1.5. It also happens that all the derby jar files in
> the path (afterall they do no harm since they are not used).
>
> 2. Someone is upgrading to JDK 1.6 and restarting this client
> application. It is still running as it should, but if the owner
> carefully examines it, she notices that the footprint of the application
> has increased and a profiler might show that there are at least one
> extra thread running (the Derby anti GC and possibly the background
> thread?) - basically the embedded driver and the derby engine might
> "automagically" have been loaded into the client depending on where
> derby.jar happened to be in the class path.

I'm not sure this scenario is a problem. The application upgraded to
Derby 10.2 at some point, I hope the 10.2 documentation will indicate
that the driver is auto-loaded in a jdk 1.6 environment.

Thus this is fully documented behaviour that any application developer
must understand.

Dan.