db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jean T. Anderson" <...@bristowhill.com>
Subject Re: Self-configuring embedded Derby applications
Date Mon, 19 Jun 2006 17:18:38 GMT
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.

Where do we recommend against this?

We document precedence of properties at
http://db.apache.org/derby/docs/dev/tuning/ctunsetprop23308.html and
also how to protect database-wide properties at
http://db.apache.org/derby/docs/dev/tuning/ctunsetprop824533.html .  I'm
not spotting any general recommendation against setting Derby properties
programmatically, though it might be there. If so, we might want to
promote that recommendation in more places.


> 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