db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Charlie Kelly <Char...@CharlieKelly.com>
Subject Re: Self-configuring embedded Derby applications
Date Mon, 19 Jun 2006 16:45:50 GMT
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 
    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.

Charlie Kelly

P.S. What is a "Heisenbug"?

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

View raw message