[ 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. -- 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
