db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Self-configuring embedded Derby applications
Date Mon, 19 Jun 2006 15:50:41 GMT
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 

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 

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.


View raw message