db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: Autoloading of JDBC drivers considered harmful?
Date Tue, 30 May 2006 15:43:11 GMT
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?

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?

Dan.



Mime
View raw message