db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Driver autoloading and engine booting
Date Fri, 16 Jun 2006 22:54:55 GMT
My vote:

- Document it for 10.2

- Log a bug

- Work on fixing it by booting on first connection rather than when the 
driver is loaded.

-1 on removing the autoloading feature, unless people have evidence that 
this is going to cause real problems for our users.


Rick Hillegas wrote:
> This topic was raised in an earlier email thread 
> (http://comments.gmane.org/gmane.comp.apache.db.derby.devel/20899) but 
> it does not appear that we agreed on a solution. I would like to re-open 
> this topic and hopefully we can converge on how we want to handle this 
> issue.
> Olav has analyzed a problematic interaction between 
> JDBC4-driver-autoloading and Derby-embedded-engine-booting. In addition 
> to the above email thread, the problem is also discussed in DERBY-1399. 
> Here's a brief sketch of the issue:
> a) With JDBC4, vendors mark their jar files to indicate the names of 
> jdbc drivers in those jars. During the lifetime of a vm, the very first 
> request for a Connection causes the DriverManager to look inside all of 
> the jars and register all indicated jdbc drivers.
> b) When our embedded driver registers itself, it also boots the engine, 
> using whatever derby properties are currently visible. Typically, the 
> engine stays booted for the lifetime of the vm.
> This can cause a Heisenbug in the following scenario:
> o The customer runs two applications in the same vm: EmbeddedApp and 
> OtherApp.
> o Before getting its first Connection, the EmbeddedApp hand-crafts its 
> own derby properties to configure the engine's behavior.
> o OtherApp could be an application which uses the Derby client driver or 
> some other jdbc driver.
> o If OtherApp runs before EmbeddedApp, then the engine will boot without 
> the hand-crafted properties.
> o It may not be deterministic whether OtherApp or EmbeddedApp runs 
> first. Sometimes you get the right engine properties and sometimes you 
> don't.
> It is worth pointing out that this Heisenbug can occur today, pre-JDBC4, 
> if OtherApp is another embedded Derby application. 
> JDBC4-driver-autoloading broadens the family of affected scenarios. It 
> is hard to say how much the family is broadened.
> It is probably worthwhile documenting this Heisenbug somewhere in our 
> user guides and release notes. In addition, two solutions have been 
> proposed for eliminating the extra exposure introduced by JDBC4. Neither 
> of these approaches addresses the pre-JDBC4 case:
> 1) Remove the JDBC4-driver-autoloading. This removes a useful 
> ease-of-development feature and makes us fail to be JDBC4-compliant.
> 2) Don't boot the engine when registering the embedded driver. Instead, 
> boot the engine the first time that someone requests an embedded 
> Connection. This approach involves a lot of testing.
> In addition, we could
> 3) Decide that the extra exposure is minimal and not do anything besides 
> document it.
> I hope that the community can agree on the severity of this extra 
> exposure and on the best approach for handling it. Please share your 
> opinions.
> Thanks,
> -Rick

View raw message