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: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.2.0.0, 10.1.2.1,
10.1.3.0, 10.1.2.2, 10.1.2.3, 10.3.0.0, 10.1.2.4, 10.1.2.5, 10.1.4.0, 10.1.3.1
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 it forces the
applications to run in a deterministic order.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
