db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: Engine booting, was: Autoloading of JDBC drivers considered harmful?
Date Tue, 30 May 2006 19:12:43 GMT
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.


View raw message