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
