I think the issue of derby.system.home and two databases running in the
same VM is a symptom of a wider problem where I am not convinced we
actually work running two instances in the same VM. Derby makes use of
a lot of system properties; if you have two instances, it seems to me
that they will always be at war with each other when trying to configure
Derby.
I would like to bet that if we built a test trying to do this sort of
thing we would quickly find that it's problematic. But not actually
having done this test myself, I can't say for sure. Has anyone tried this?
David
Rick Hillegas (JIRA) wrote:
[ http://issues.apache.org/jira/browse/DERBY-1428?page=comments#action_12416995 ]
Rick Hillegas commented on DERBY-1428:
--------------------------------------
I think this behavior is very puzzling to the system administrator, the
end-user, and tech support. What happens if a system administrator uses one VM
to deploy two embedded derby applications, each of which sets derby.system.home
to a different location and/or generates custom derby.properties? Only one of
the applications can win. This kind of behavior is going to be particularly
frustrating if it is intermittent.
I understand that this behavior may be so central to Derby's operation that we
can't change it. Maybe we could log a warning if we notice that
derby.system.home or derby.properties change within the lifetime of a vm. It
would be nice to provide tech support some kind of tools for identifying this
problem.
Perhaps this is a documentation bug? Maybe the Admin or Developer's Guide
should say: You can code your application this way, but if you do, be aware
that it may not play well with other Derby applications.
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 the
self-configuring EmbeddedApp runs first.
