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

          Gavin made changes -
          Workflow jira [ 12374055 ] Default workflow, editable Closed status [ 12799030 ]
          Mike Matrigali made changes -
          Labels derby_triage10_8
          Urgency Low
          Dag H. Wanvik made changes -
          Affects Version/s 10.1.3.3 [ 12313478 ]
          Affects Version/s 10.1.4.0 [ 12311950 ]
          Daniel John Debrunner made changes -
          Priority Major [ 3 ] Minor [ 4 ]
          Summary Generating derby properties on the fly can lead to non-deterministic engine startup behavior Multiple applications within a single jvm generating derby properties on the fly can lead to non-deterministic engine startup behavior
          Mike Matrigali made changes -
          Component/s Services [ 11415 ]
          Component/s Store [ 11412 ]
          Rick Hillegas made changes -
          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 it forces the applications to run in a deterministic order.
          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.
          Rick Hillegas made changes -
          Field Original Value New Value
          Link This issue relates to DERBY-1429 [ DERBY-1429 ]
          Rick Hillegas created issue -

            People

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

              Dates

              • Created:
                Updated:

                Development