Hi Charlie,
Thanks for your quick response.
Charlie Kelly wrote:
Hi Rick,
We use Derby "deeply embedded" within Eclipse (osgi) and JBoss
aaplications in conjunction with Hibernate object-relational mappings,
therefore, we can't always control when the application makes calls to
the Derby jar.
We use Hibernate+Derby in two ways:
1) a semi-automated process that generates schemata from our object
model
2) a runtime process that passes schemata and Hibernate+Derby
properties into the application
The properties are static with respect to our object model, but
dynamic from osgi and JBoss perspectives.
Thanks
Charlie Kelly
P.S. What is a "Heisenbug"?
Sorry for the jargon. It's a term which Jim Gray coined for bugs which
arise from non-deterministic behavior and which can disappear when you
instrument the application to look for them.
Regards,
-Rick
Rick Hillegas wrote:
Dear Derby users,
I would like to understand if anyone thinks that they might be
affected by the following issue. This issue affects customers who do
the following:
o Run an embedded Derby application which generates its own Derby
properties on the fly.
o In the same VM, run other JDBC applications. These other
applications could request Connections to DB2, Oracle, Derby, or any
other database.
In general, we recommend against generating Derby properties on the
fly. This general problem is described in DERBY-1428. However, the
Derby mainline (slated to become release 10.2) expands this problem,
as described in DERBY-1429. For a workaround, see the Release Note
attached to DERBY-930.
Here is more detail on this 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.
I would like to understand how much the family is broadened. Please
let me know if you think this problem will affect you.
Thanks,
-Rick
