db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <derby-...@db.apache.org>
Subject [jira] Commented: (DERBY-1428) Generating derby properties on the fly can lead to non-deterministic engine startup behavior
Date Mon, 19 Jun 2006 21:24:31 GMT
    [ http://issues.apache.org/jira/browse/DERBY-1428?page=comments#action_12416810 ] 

Rick Hillegas commented on DERBY-1428:

Kathey adds the following:

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
-  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:

> Generating derby properties on the fly can lead to non-deterministic engine startup behavior
> --------------------------------------------------------------------------------------------
>          Key: DERBY-1428
>          URL: http://issues.apache.org/jira/browse/DERBY-1428
>      Project: Derby
>         Type: Bug

>   Components: Store
>     Versions:,,,,,,,,,,,,,
>     Reporter: Rick Hillegas

> A Heisenbug can arise if more than one embedded Derby application runs in the same VM
and at least one of them generates derby properties on the fly. Here's the problem scenario:
> o The customer runs two embedded Derby apps in the same VM: EmbeddedApp and OtherApp.
> o EmbeddedApp generates derby properties on the fly before connecting to a database and
triggering engine startup.
> o Whether the engine picks up those generated properties depends on whether EmbeddedApp
or OtherApp runs first.
> Here are two workarounds for the problem:
> 1) Don't generate derby properties on the fly. Instead, specify them on the VM startup
command. Or specify them in a $DERBY_HOME/derby.properties file which is generated before
the VM comes up and which does not change during the lifetime of the VM.
> 2) If you can't do (1), then modify the VM startup script so that the self-configuring
EmbeddedApp runs first.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

View raw message