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
