Derby
  1. Derby
  2. DERBY-1428

Multiple applications within a single jvm generating derby properties on the fly can lead to non-deterministic engine startup behavior

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Minor Minor
    • Resolution: Unresolved
    • Affects Version/s: 10.0.2.0, 10.0.2.1, 10.0.2.2, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.1.3.3, 10.2.1.6, 10.3.1.4
    • Fix Version/s: None
    • Component/s: Services
    • Urgency:
      Low

      Description

      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.

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          In workaround (2) be explicit about the order in which the applications have to run.

          Show
          Rick Hillegas added a comment - In workaround (2) be explicit about the order in which the applications have to run.
          Hide
          Rick Hillegas added a comment -

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

          Show
          Rick Hillegas added a comment - 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 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
          Hide
          Daniel John Debrunner added a comment -

          Is this a bug? - Derby is behaving as desgined.

          Show
          Daniel John Debrunner added a comment - Is this a bug? - Derby is behaving as desgined.
          Hide
          Rick Hillegas added a comment -

          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.

          Show
          Rick Hillegas added a comment - 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.
          Hide
          Mike Matrigali added a comment -

          changing component from store to services. This is really a monitor issue.

          Show
          Mike Matrigali added a comment - changing component from store to services. This is really a monitor issue.
          Hide
          Daniel John Debrunner added a comment -

          Improve the summary to indicate this is an issue with multiple applications only.

          Show
          Daniel John Debrunner added a comment - Improve the summary to indicate this is an issue with multiple applications only.
          Hide
          Mike Matrigali added a comment -

          10.8 derby triage.

          Show
          Mike Matrigali added a comment - 10.8 derby triage.

            People

            • Assignee:
              Unassigned
              Reporter:
              Rick Hillegas
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:

                Development