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
