Daniel John Debrunner <[EMAIL PROTECTED]> writes:
> Knut Anders Hatlen wrote:
>
>> Olav Sandstaa <[EMAIL PROTECTED]> 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:
http://java.sun.com/docs/books/jls/first_edition/html/12.doc.html#44850
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:
http://java.sun.com/docs/books/jls/second_edition/html/execution.doc.html#74249
http://java.sun.com/docs/books/jls/third_edition/html/execution.html#12.7
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
