Derby
  1. Derby
  2. DERBY-1429

Additional vulnerability to non-deterministic startup behavior when applications generate derby properties on the fly

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Duplicate
    • Affects Version/s: 10.2.1.6
    • Fix Version/s: 10.2.1.6
    • Component/s: Services
    • Labels:
      None

      Description

      JDBC4 driver-autoloading, introduced by DERBY-930, increases the exposure to non-deterministic startup behavior described in DERBY-1428. With the introduction of driver-autloading, DERBY-1428 can be triggered if OtherApp is any application which uses a JDBC driver. That is, OtherApp could use a Derby client driver, the DB2JCC driver, the Oracle client driver, etc.. The extra exposure arises because, with driver auto-loading, all JDBC drivers are registered and the Derby engine boots the first time some application asks for a Connection.

      The issues are summarized in an email thread http://mail-archives.apache.org/mod_mbox/db-derby-dev/200606.mbox/browser and bug report DERBY-1399.

      Workarounds are similar to those for DERBY-1428:

      1) Determine the derby properties BEFORE the VM starts.

      2) If that is not possible, then force the self-configuring embedded application to run first.

        Issue Links

          Activity

          Hide
          Rick Hillegas added a comment -

          We could separate out the booting of the engine from the registration of the embedded driver. This would eliminate this bug in the case that there is only one embedded Derby application in the VM.

          However, we can't solve the general problem of two self-configuring Derby applications running in the same VM. Only one of them can win. The user guide needs to strongly recommend that application designers avoid generating Derby properties on the fly.

          Show
          Rick Hillegas added a comment - We could separate out the booting of the engine from the registration of the embedded driver. This would eliminate this bug in the case that there is only one embedded Derby application in the VM. However, we can't solve the general problem of two self-configuring Derby applications running in the same VM. Only one of them can win. The user guide needs to strongly recommend that application designers avoid generating Derby properties on the fly.
          Hide
          Mike Matrigali added a comment -

          This issue should be handled by the monitor, not the store.

          Show
          Mike Matrigali added a comment - This issue should be handled by the monitor, not the store.
          Hide
          Rick Hillegas added a comment -

          Marking as duplicate of DERBY-1459, which describes the problem cases better.

          Show
          Rick Hillegas added a comment - Marking as duplicate of DERBY-1459 , which describes the problem cases better.

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development