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
