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: local policy)
Date: Tue, 30 May 2006 13:34:40 +0200
From: Knut Anders Hatlen <Knut.Hatlen@Sun.COM>
Subject: Re: Autoloading of JDBC drivers considered harmful?
In-reply-to: <447C25A4.8090708@sun.com>
Sender: Knut.Hatlen@Sun.COM
To: derby-dev@db.apache.org
Message-id: <wjo8k683eofj.fsf@sun.com>
Organization: Sun Microsystems
MIME-version: 1.0
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
References: <44778871.4030006@sun.com> <447B02B5.6080600@sun.com>
 <447C25A4.8090708@sun.com>
User-Agent: Gnus/5.1008 (Gnus v5.10.8) Emacs/22.0.50 (usg-unix-v)

Olav Sandstaa <Olav.Sandstaa@Sun.COM> writes:

> To confirm that this was not something special triggered by the DB2
> driver, I ran the same test program loading the Derby Network client,
> MySQL and PostgreSQL JDBC drivers. With derby.jar in the class path
> the embedded driver and engine are loaded in all cases.

It sounds like the problem is that the loading of the embedded JDBC
driver includes starting and initializing the engine. Other
(non-embedded) databases don't have this problem because loading the
driver simply registers it with the DriverManager. Perhaps we could
solve the problem by separating registration of the driver and startup
of the engine? That is, Class.forName("EmbeddedDriver") only registers
the driver, but no reading of system properties or starting of service
threads happens until getConnection() is called.

Another issue with Derby and autoloading is that it only happens once
per JVM. If you do a getConnection("jdbc:derby:;shutdown=true"), the
driver is unloaded and won't be reloaded unless you do a
Class.forName(). So this code

  Connection c = DriverManager.getConnection("jdbc:derby:mydb");
  doSomethingWithConnection(c);
  try {
    DriverManager.getConnection("jdbc:derby:;shutdown=true");
  } catch (SQLException) { /* shutdown exception */ }

runs fine the first time it is executed, but if it is executed later
within the same JVM, it fails with "no suitable driver".

I admit this is a special case, but at least it shows that you cannot
go through your code and remove all calls to Class.forName(driver) and
expect the autoloading to work automagically with Derby today.

-- 
Knut Anders