Derby
  1. Derby
  2. DERBY-1762

Setting the derby.locks.waitTimeout as a system property using System.setProperty does not affect booted databases

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Minor Minor
    • Resolution: Invalid
    • Affects Version/s: 10.0.2.0, 10.0.2.1, 10.1.1.0, 10.1.2.1, 10.1.3.1, 10.2.1.6, 10.3.1.4
    • Fix Version/s: None
    • Component/s: Documentation, Services
    • Labels:
      None

      Description

      Tuning guide for derby.locks.waitTimeout states it is a dynamic property, but when set as a system property using System.setProperty it does not change the timeout for any databases already booted. It might change it for databases that are booted after the change, I didn't test that.

      If the property is set as a database property then it is dynamic, taking effect immediately.

      Guess it affects all versions.

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          Triaged for 10.5.2.

          I believe the described behaviour is in accordance with the
          documentation, so I'm closing this bug as invalid.

          Here are the relevant sections from the manuals:

          Reference manual, Dynamic and static properties -
          http://db.apache.org/derby/docs/10.5/ref/crefproperdynstat.html:

          > Only properties set in the following ways have the potential to be dynamic:
          >
          > * As database-wide properties
          > * As system-wide properties via a Properties object in the
          > application in which the Derby engine is embedded

          Following from the above, since it's set as a system-wide property in
          this scenario, it needs to follow the rules described in Reference
          manual, Changing the system-wide properties programmatically, Using a
          Properties object within an application or statement -
          http://db.apache.org/derby/docs/10.5/devguide/cdevsetprop11561.html#cdevsetprop11561__propobj:

          > In embedded mode, your application runs in the same JVM as Derby, so
          > you can also set system properties within an application using a
          > Properties object before loading the Derby JDBC driver.

          Since the Derby JDBC driver has already been loaded in the scenario
          described in this bug report, changing a system property is not
          guaranteed to have any effect.

          Show
          Knut Anders Hatlen added a comment - Triaged for 10.5.2. I believe the described behaviour is in accordance with the documentation, so I'm closing this bug as invalid. Here are the relevant sections from the manuals: Reference manual, Dynamic and static properties - http://db.apache.org/derby/docs/10.5/ref/crefproperdynstat.html: > Only properties set in the following ways have the potential to be dynamic: > > * As database-wide properties > * As system-wide properties via a Properties object in the > application in which the Derby engine is embedded Following from the above, since it's set as a system-wide property in this scenario, it needs to follow the rules described in Reference manual, Changing the system-wide properties programmatically, Using a Properties object within an application or statement - http://db.apache.org/derby/docs/10.5/devguide/cdevsetprop11561.html#cdevsetprop11561__propobj: > In embedded mode, your application runs in the same JVM as Derby, so > you can also set system properties within an application using a > Properties object before loading the Derby JDBC driver. Since the Derby JDBC driver has already been loaded in the scenario described in this bug report, changing a system property is not guaranteed to have any effect.

            People

            • Assignee:
              Unassigned
              Reporter:
              Daniel John Debrunner
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development