You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Olav Sandstaa <Ol...@Sun.COM> on 2006/05/27 01:00:01 UTC
Autoloading of JDBC drivers considered harmful?
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 have not tested that this happens yet, but will try it out on Monday.
Regards,
Olav
Re: Engine booting, was: Autoloading of JDBC drivers considered
harmful?
Posted by John Embretsen <Jo...@Sun.COM>.
Kathey Marsden wrote:
> Rick Hillegas wrote:
[SNIP]
>>>> 1) This is a Derby bug which we could fix if we separated driver
>>>> initialization from engine booting.
>>>>
>>>> 2) This is an odd Derby behavior which we should document: If you
>>>> explicitly shut down the engine, then if you want to get a
>>>> connection later, you must explicitly reboot the engine.
>>>>
>>>> 3) This is a jdk bug. The DriverManager should rerun its autoloading
>>>> logic if the registered drivers can't get a connection.
>>>>
>>>> I think we will have a hard time convincing the jdk folks that this
>>>> is their bug. So I think the choice comes down to (1) vs. (2). I can
>>>> see this go either way. My instinct is to opt for (2) because it
>>>> seems less risky.
>>>>
>>> What are the risks of 1?
>>
>>
>> I don't know. I'm just being cautious about a code path which is
>> executed every time you boot the engine.
>
> If it proves to not be a significant risk. #1 would get my vote as it
> could resolve the issues without any special action needed on the part
> of users. #2 does not resolve Olav's concern I think.
I am not so sure #1 does not have consequences for users. If we decide
to go with this option, the behavior of applications using the embedded
server configuration with properties
(derby.drda.startNetworkServer=true) would change noticeably. Currently
the (embedded) network server starts once the embedded driver is loaded
- I'm guessing this will no longer be the case if we separate engine
boot from driver loading.
It might be OK to do it though, as long as it is documented properly.
--
John
Re: Engine booting, was: Autoloading of JDBC drivers considered harmful?
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
> Kathey Marsden wrote:
>
>> Rick Hillegas wrote:
>>
>>>
>>> Let me summarize the odd behavior:
>>>
>>> o Under JDBC4, if you explicitly shut down the Derby engine, then
>>> subsequent calls to DriverManager.getConnection() will fail.
>>> o There is a workaround: Explictly reboot the Derby engine by
>>> issuing Class.forName() on the embedded driver.
>>>
>> I think Olov also brought up the good point that the Derby engine
>> will start for client programs just because the derby.jar is in the
>> classpath.
>>
>>> You could look at this problem from the following angles:
>>>
>>> 1) This is a Derby bug which we could fix if we separated driver
>>> initialization from engine booting.
>>>
>>> 2) This is an odd Derby behavior which we should document: If you
>>> explicitly shut down the engine, then if you want to get a
>>> connection later, you must explicitly reboot the engine.
>>>
>>> 3) This is a jdk bug. The DriverManager should rerun its autoloading
>>> logic if the registered drivers can't get a connection.
>>>
>>> I think we will have a hard time convincing the jdk folks that this
>>> is their bug. So I think the choice comes down to (1) vs. (2). I can
>>> see this go either way. My instinct is to opt for (2) because it
>>> seems less risky.
>>>
>> What are the risks of 1?
>
>
> I don't know. I'm just being cautious about a code path which is
> executed every time you boot the engine.
If it proves to not be a significant risk. #1 would get my vote as it
could resolve the issues without any special action needed on the part
of users. #2 does not resolve Olav's concern I think.
Kathey
Re: Engine booting, was: Autoloading of JDBC drivers considered
harmful?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Kathey Marsden wrote:
> Rick Hillegas wrote:
>
>>
>> Let me summarize the odd behavior:
>>
>> o Under JDBC4, if you explicitly shut down the Derby engine, then
>> subsequent calls to DriverManager.getConnection() will fail.
>> o There is a workaround: Explictly reboot the Derby engine by issuing
>> Class.forName() on the embedded driver.
>>
> I think Olov also brought up the good point that the Derby engine
> will start for client programs just because the derby.jar is in the
> classpath.
>
>> You could look at this problem from the following angles:
>>
>> 1) This is a Derby bug which we could fix if we separated driver
>> initialization from engine booting.
>>
>> 2) This is an odd Derby behavior which we should document: If you
>> explicitly shut down the engine, then if you want to get a connection
>> later, you must explicitly reboot the engine.
>>
>> 3) This is a jdk bug. The DriverManager should rerun its autoloading
>> logic if the registered drivers can't get a connection.
>>
>> I think we will have a hard time convincing the jdk folks that this
>> is their bug. So I think the choice comes down to (1) vs. (2). I can
>> see this go either way. My instinct is to opt for (2) because it
>> seems less risky.
>>
> What are the risks of 1?
I don't know. I'm just being cautious about a code path which is
executed every time you boot the engine.
>
> Kathey
>
>
Re: Engine booting, was: Autoloading of JDBC drivers considered harmful?
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
>
> Let me summarize the odd behavior:
>
> o Under JDBC4, if you explicitly shut down the Derby engine, then
> subsequent calls to DriverManager.getConnection() will fail.
> o There is a workaround: Explictly reboot the Derby engine by issuing
> Class.forName() on the embedded driver.
>
I think Olov also brought up the good point that the Derby engine will
start for client programs just because the derby.jar is in the classpath.
> You could look at this problem from the following angles:
>
> 1) This is a Derby bug which we could fix if we separated driver
> initialization from engine booting.
>
> 2) This is an odd Derby behavior which we should document: If you
> explicitly shut down the engine, then if you want to get a connection
> later, you must explicitly reboot the engine.
>
> 3) This is a jdk bug. The DriverManager should rerun its autoloading
> logic if the registered drivers can't get a connection.
>
> I think we will have a hard time convincing the jdk folks that this is
> their bug. So I think the choice comes down to (1) vs. (2). I can see
> this go either way. My instinct is to opt for (2) because it seems
> less risky.
>
What are the risks of 1?
Kathey
Engine booting, was: Autoloading of JDBC drivers considered harmful?
Posted by Rick Hillegas <Ri...@Sun.COM>.
Hi Olav and Knut Anders,
Thanks for running these experiments and uncovering this behavior.
Driver-autoloading, of course, is a required JDBC4 feature. If Derby
doesn't play well with driver-autoloading, then we have a Derby bug we
have to fix. Perhaps, if we squint at it, we just have odd behavior that
needs documentation. Or perhaps this is a jdk bug.
Let me summarize the odd behavior:
o Under JDBC4, if you explicitly shut down the Derby engine, then
subsequent calls to DriverManager.getConnection() will fail.
o There is a workaround: Explictly reboot the Derby engine by issuing
Class.forName() on the embedded driver.
You could look at this problem from the following angles:
1) This is a Derby bug which we could fix if we separated driver
initialization from engine booting.
2) This is an odd Derby behavior which we should document: If you
explicitly shut down the engine, then if you want to get a connection
later, you must explicitly reboot the engine.
3) This is a jdk bug. The DriverManager should rerun its autoloading
logic if the registered drivers can't get a connection.
I think we will have a hard time convincing the jdk folks that this is
their bug. So I think the choice comes down to (1) vs. (2). I can see
this go either way. My instinct is to opt for (2) because it seems less
risky.
Hey Dan,
What are your thoughts?
Regards,
-Rick
Knut Anders Hatlen wrote:
>Olav Sandstaa <Ol...@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.
>
>
>
Re: Autoloading of JDBC drivers considered harmful?
Posted by Olav Sandstaa <Ol...@Sun.COM>.
Knut Anders Hatlen wrote:
> 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.
>
It seems like your example does not work even if you do a
explicit Class.forName() to reload the driver. The following program
(attempts to) reload the driver after having done a system shutdown:
import java.sql.DriverManager;
import java.sql.SQLException;
class AutoLoad {
public static void main(String[] args) {
System.out.println("Load driver 1");
try {
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
} catch (Exception e) {
System.out.println("FAIL: Failed to load driver: " + e);
}
System.out.println("Unload driver 1");
try {
DriverManager.getConnection("jdbc:derby:;shutdown=true");
} catch (SQLException se) {
System.out.println("Shutdown returned: " + se);
}
try {
Thread.sleep(1000);
}
catch (InterruptedException e) {
// Ignore exception
}
System.gc();
System.out.println("Load driver 2");
try {
Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
} catch (Exception e) {
System.out.println("FAIL: Failed to load driver: " + e);
}
System.out.println("Unload driver 2");
try {
DriverManager.getConnection("jdbc:derby:;shutdown=true");
} catch (SQLException se) {
System.out.println("Shutdown returned: " + se);
}
}
}
The following output is produced:
Load driver 1
Unload driver 1
Shutdown returned: java.sql.SQLException: Derby system shutdown.
Load driver 2
Unload driver 2
Shutdown returned: java.sql.SQLException: No suitable driver found for
jdbc:derby:;shutdown=true
So it seems like the second attempt to load the driver does not do
what is intended.
BUT: if you use class.forName(...).newInstance() the driver will be
reloaded the second time. Now the program writes:
Load driver 1
Unload driver 1
Shutdown returned: java.sql.SQLException: Derby system shutdown.
Load driver 2
Unload driver 2
Shutdown returned: java.sql.SQLException: Derby system shutdown.
Regards,
Olav
Re: Autoloading of JDBC drivers considered harmful?
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Daniel John Debrunner <dj...@apache.org> writes:
> Knut Anders Hatlen wrote:
>
>> Olav Sandstaa <Ol...@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:
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
Re: Autoloading of JDBC drivers considered harmful?
Posted by Daniel John Debrunner <dj...@apache.org>.
Knut Anders Hatlen wrote:
> Olav Sandstaa <Ol...@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.
Re: Autoloading of JDBC drivers considered harmful?
Posted by "Lance J. Andersen" <La...@Sun.COM>.
Daniel John Debrunner wrote:
> Knut Anders Hatlen wrote:
>
>
>> 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".
>>
>
> Is this special to Derby, or is it true for any JDBC driver?
>
> Do other drivers provide the ability to de-register themselves from the
> DriverManager? Or can an application just call?
>
> DriverManager.deregisterDriver(DriverManager.getDriver(url));
>
this is a public method, like anything on DriverManager, but this is not
a method normally used by developers of JDBC applications.
> Dan.
>
>
>
>
Re: Autoloading of JDBC drivers considered harmful?
Posted by Daniel John Debrunner <dj...@apache.org>.
Knut Anders Hatlen wrote:
> 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".
Is this special to Derby, or is it true for any JDBC driver?
Do other drivers provide the ability to de-register themselves from the
DriverManager? Or can an application just call?
DriverManager.deregisterDriver(DriverManager.getDriver(url));
Dan.
Re: Autoloading of JDBC drivers considered harmful?
Posted by Knut Anders Hatlen <Kn...@Sun.COM>.
Olav Sandstaa <Ol...@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
Re: Autoloading of JDBC drivers considered harmful?
Posted by Olav Sandstaa <Ol...@Sun.COM>.
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.
Regards,
Olav
Olav Sandstaa wrote:
> The following program if run with jdk 1.6 and derby.jar in the class
> path will load the embedded Derby driver and engine as well as the DB2
> driver:
>
> class AutoLoad {
>
> public static void main(String[] args) {
> try {
> Class.forName("com.ibm.db2.jcc.DB2Driver");
> } catch (ClassNotFoundException e) {
> System.out.println("FAIL: Failed to load driver: " + e);
> }
> }
> }
>
> The call stack when the Embedded driver is loaded looks like this:
>
> at
> org.apache.derby.jdbc.EmbeddedDriver.<init>(EmbeddedDriver.java:102)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
> at
> sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
>
> at
> sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
>
> at java.lang.reflect.Constructor.newInstance(Constructor.java:506)
> at java.lang.Class.newInstance0(Class.java:355)
> at java.lang.Class.newInstance(Class.java:308)
> at
> java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345)
> at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
> at java.sql.DriverService.run(DriverManager.java:622)
> at java.security.AccessController.doPrivileged(Native Method)
> at
> java.sql.DriverManager.loadInitialDrivers(DriverManager.java:477)
> at java.sql.DriverManager.initialize(DriverManager.java:578)
> at java.sql.DriverManager.registerDriver(DriverManager.java:268)
> at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:46)
> at java.lang.Class.forName0(Native Method)
> at java.lang.Class.forName(Class.java:169)
> at AutoLoad.main(AutoLoad.java:8)
>
> AutoMagic :-)
>
> ..olav
Re: Autoloading of JDBC drivers considered harmful?
Posted by Olav Sandstaa <Ol...@Sun.COM>.
Olav Sandstaa wrote:
> I have not tested that this happens yet, but will try it out on Monday.
The following program if run with jdk 1.6 and derby.jar in the class
path will load the embedded Derby driver and engine as well as the DB2
driver:
class AutoLoad {
public static void main(String[] args) {
try {
Class.forName("com.ibm.db2.jcc.DB2Driver");
} catch (ClassNotFoundException e) {
System.out.println("FAIL: Failed to load driver: " + e);
}
}
}
The call stack when the Embedded driver is loaded looks like this:
at
org.apache.derby.jdbc.EmbeddedDriver.<init>(EmbeddedDriver.java:102)
at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native
Method)
at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
at java.lang.reflect.Constructor.newInstance(Constructor.java:506)
at java.lang.Class.newInstance0(Class.java:355)
at java.lang.Class.newInstance(Class.java:308)
at java.util.ServiceLoader$LazyIterator.next(ServiceLoader.java:345)
at java.util.ServiceLoader$1.next(ServiceLoader.java:421)
at java.sql.DriverService.run(DriverManager.java:622)
at java.security.AccessController.doPrivileged(Native Method)
at java.sql.DriverManager.loadInitialDrivers(DriverManager.java:477)
at java.sql.DriverManager.initialize(DriverManager.java:578)
at java.sql.DriverManager.registerDriver(DriverManager.java:268)
at com.ibm.db2.jcc.DB2Driver.<clinit>(DB2Driver.java:46)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:169)
at AutoLoad.main(AutoLoad.java:8)
AutoMagic :-)
..olav
Re: Autoloading of JDBC drivers considered harmful?
Posted by Daniel John Debrunner <dj...@apache.org>.
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.