You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-user@db.apache.org by Rick Hillegas <Ri...@Sun.COM> on 2006/06/19 17:50:41 UTC
Self-configuring embedded Derby applications
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
Re: Self-configuring embedded Derby applications
Posted by Kathey Marsden <km...@sbcglobal.net>.
Rick Hillegas wrote:
>
> 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.
>
I think DERBY-1428 and DERBY-149 are not really related to generating
derby.properties on the fly they are related to when Derby boots and
when derby.system.home is recognized. derby.system.home *has* to be set
with a system property. Anyone who sets derby.system.home or static
derby properties programatically with System.setProperty() may be
affected if they do not have control over their calling context.
Another driver might cause derby to be autoloaded before these
properties are set. Perhaps these issues would be better worded as:
"Derby can have non-deterministic behaviour when derby.system.home or
other static properties are set with System.setProperty()"
More common reported symptoms will likely be after upgrading to
Derby 10.2 and JDK 1.6 users will report the following systems because
derby.system.home is not picked up properly.
- I get XJ004.C=Database ''...'' not found. (Derby is looking in the
wrong place for the db)
- There is nothing in my database. (create=true was on
the url and so app created a new db in the wrong place)
- My database was created in the wrong place.
- Properties set in derby.properties are not being picked up.
Some more info:
http://www.nabble.com/Re%3A--jira--Commented%3A-%28DERBY-930%29-Add-support-for-autoloading-of-Derby-client-drivers-p4909085.html
Kathey
Re: Self-configuring embedded Derby applications
Posted by Rick Hillegas <Ri...@Sun.COM>.
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
>>
>>
>>
>>
>>
>
>
Re: Self-configuring embedded Derby applications
Posted by Charlie Kelly <Ch...@CharlieKelly.com>.
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"?
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
>
>
>
>
>
Re: Self-configuring embedded Derby applications
Posted by "Jean T. Anderson" <jt...@bristowhill.com>.
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.
-jean
> 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
>
>