db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Driver autoloading and engine booting
Date Fri, 16 Jun 2006 22:48:21 GMT
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





Mime
View raw message