db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Autoloading of JDBC drivers considered harmful?
Date Tue, 30 May 2006 17:39:16 GMT
Daniel John Debrunner <djd@apache.org> writes:

> Knut Anders Hatlen wrote:
>> 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.
> How do other drivers avoid the garbage collection problem the antigc
> thread is there for?

I can't find any such magic in the client driver, so maybe the antigc
thread is not needed?

> Back in jdk 1.1 days one (with Cloudscape) would load the driver and
> then if there was too much delay before calling
> DriverManager.getConnection, the DriverManager class itself would get
> garbage collected and thus shutdown Cloudscape. This seemed to be more
> true of Cloudscpae, than other JDBC drivers, as it was running as an
> embedded server, there could be long periods of time between connection
> requests.
> Was there some change in the java specs to allow classes like
> DriverManager not to be garbage collected, or do all the JDBC drivers
> have some mechanism to avoid the driver disappearing?

A class cannot be garbage collected until the classloader that loaded
it has been garbage collected, so if DriverManager is loaded by the
system classloader, it shouldn't be collected. I think older versions
of the Java Language Specification didn't state this clearly.

First edition said:

  A Java Virtual Machine may provide mechanisms whereby classes are
  unloaded. The details of such mechanisms are not specified in this
  version of the Java Language Specification. (...)

  A class may not be unloaded while any instance of it is still
  reachable (§12.6). A class or interface may not be unloaded while
  the Class object that represents it is still reachable.

Second and third edition say:

  An implementation of the Java programming language may unload
  classes. A class or interface may be unloaded if and only if its
  defining class loader may be reclaimed by the garbage collector as
  discussed in §12.6. Classes and interfaces loaded by the bootstrap
  loader may not be unloaded.


  Since we can never guarantee that unloading a class or interface
  whose loader is potentially reachable will not cause reloading, and
  reloading is never transparent, but unloading must be transparent,
  it follows that one must not unload a class or interface while its
  loader is potentially reachable. A similar line of reasoning can be
  used to deduce that classes and interfaces loaded by the bootstrap
  loader can never be unloaded.

Knut Anders

View raw message