Derby
  1. Derby
  2. DERBY-4884

DatabasePropertyTestSetup cannot change static properties in encrypted databases

    Details

    • Type: Bug Bug
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: 10.7.1.1
    • Fix Version/s: 10.7.1.1
    • Component/s: Test
    • Labels:
      None

      Description

      DatabasePropertyTestSetup needs to reboot the database in order to set static properties. In tests with encrypted databases, the database cannot be rebooted because the boot password is only known inside the setUp() method of the decorator created by Decorator.encryptedDatabase().

      One of the problems that results from this, is that BlobClob4Blob test cannot reduce the lock timeout for the encrypted variant of the test. Since there are four test cases that wait for a lock timeout, the test takes almost four minutes longer than it would have if the lock timeout had been reduced.

      1. derby-4884-2a.diff
        5 kB
        Knut Anders Hatlen
      2. derby-4884-1a.diff
        16 kB
        Knut Anders Hatlen

        Issue Links

          Activity

          Hide
          Knut Anders Hatlen added a comment -

          I've found two more tests, in addition to BlobClob4BlobTest, that have this problem:

          • StressMultiTest: This test works around the problem by using a SystemPropertyTestSetup for static database properties instead of using DatabasePropertyTestSetup. See comment in its suite() method.
          • DeadlockModeTest: Same problem as BlobClob4BlobTest. It wraps a DatabasePropertyTestSetup on top of the encryption decorator. But since the encryption decorator creates a single-use database, the DBPTS will work on the wrong database (it works on the default db since it's not inside the encryption decorator). Moving the encryption decorator outside the the DBPTS will make the rebooting of the fail because the boot password isn't available outside the encryption decorator's setUp() method. Unlike the problem in BlobClob4BlobTest, this doesn't usually make the test take unnecessarily long time, since the test isn't expected to experience timeouts or deadlocks.

          I'm working on a patch that makes the encryption decorator better integrated with the test framework. In short, I'm planning to add support for extra connection attributes in TestConfiguration, so that the necessary attributes will also be available when opening a connection outside of the decorator's setUp() method.

          Show
          Knut Anders Hatlen added a comment - I've found two more tests, in addition to BlobClob4BlobTest, that have this problem: StressMultiTest: This test works around the problem by using a SystemPropertyTestSetup for static database properties instead of using DatabasePropertyTestSetup. See comment in its suite() method. DeadlockModeTest: Same problem as BlobClob4BlobTest. It wraps a DatabasePropertyTestSetup on top of the encryption decorator. But since the encryption decorator creates a single-use database, the DBPTS will work on the wrong database (it works on the default db since it's not inside the encryption decorator). Moving the encryption decorator outside the the DBPTS will make the rebooting of the fail because the boot password isn't available outside the encryption decorator's setUp() method. Unlike the problem in BlobClob4BlobTest, this doesn't usually make the test take unnecessarily long time, since the test isn't expected to experience timeouts or deadlocks. I'm working on a patch that makes the encryption decorator better integrated with the test framework. In short, I'm planning to add support for extra connection attributes in TestConfiguration, so that the necessary attributes will also be available when opening a connection outside of the decorator's setUp() method.
          Hide
          Knut Anders Hatlen added a comment -

          Here's a patch (1a) that makes the necessary changes to the encryption decorator (Decorator.encryptedDatabase()) to support rebooting using the normal helper methods (e.g., TestConfiguration.shutdownDatabase()). It doesn't touch any of the tests that use the decorator, and there are more changes needed to make them set static properties correctly using DatabasePropertyTestSetup.

          Changes made by this patch:

          • TestConfiguration: Add support for extra connection attributes in the configuration.
          • DriverManagerConnector: Pick up connection attributes from the TestConfiguration.
          • JDBCDataSource: Pick up connection attributes from the TestConfiguration. This will make all DataSource-based connectors use the connection attributes.
          • Decorator: Use a ChangeConfigurationSetup that adds connection attributes to the current configuration when decorating encryption tests (and, because of code sharing, also collation tests). Stop creating the database in the decorator's setUp(), since the other changes makes the framework create the database automatically on the first connection attempt, just like other tests/decorators.
          • DatabaseMetaDataTest: Work-around for DERBY-4886. Since the framework changes makes openDefaultConnection() use the extra connection attributes, and DatabaseMetaDataTest is invoked by CollationTest with extra attributes, the test of getURL() in DatabaseMetaDataTest will see a different URL in client mode.

          Regression tests ran cleanly with the patch.

          Show
          Knut Anders Hatlen added a comment - Here's a patch (1a) that makes the necessary changes to the encryption decorator (Decorator.encryptedDatabase()) to support rebooting using the normal helper methods (e.g., TestConfiguration.shutdownDatabase()). It doesn't touch any of the tests that use the decorator, and there are more changes needed to make them set static properties correctly using DatabasePropertyTestSetup. Changes made by this patch: TestConfiguration: Add support for extra connection attributes in the configuration. DriverManagerConnector: Pick up connection attributes from the TestConfiguration. JDBCDataSource: Pick up connection attributes from the TestConfiguration. This will make all DataSource-based connectors use the connection attributes. Decorator: Use a ChangeConfigurationSetup that adds connection attributes to the current configuration when decorating encryption tests (and, because of code sharing, also collation tests). Stop creating the database in the decorator's setUp(), since the other changes makes the framework create the database automatically on the first connection attempt, just like other tests/decorators. DatabaseMetaDataTest: Work-around for DERBY-4886 . Since the framework changes makes openDefaultConnection() use the extra connection attributes, and DatabaseMetaDataTest is invoked by CollationTest with extra attributes, the test of getURL() in DatabaseMetaDataTest will see a different URL in client mode. Regression tests ran cleanly with the patch.
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 1032485.

          Show
          Knut Anders Hatlen added a comment - Committed revision 1032485.
          Hide
          Knut Anders Hatlen added a comment -

          Here's a second patch that makes BlobClob4BlobTest and DeadlockModeTest use the reduced timeouts when running against encrypted databases. The patch changes the order of the decorators so that the DatabasePropertyTestSetup executes inside the encryption decorator, and this ensures that it works on the encrypted database instead of on the default database.

          DeadlockModeTest had one more problem that needed to be fixed. The encrypted variant always worked on the default (non-encrypted) database, not only when setting the timeouts, but also when doing database operations in the test case. The reason for this was that all the database connections were opened in helper threads, and the decorators only change the test configuration for the current thread (in a thread local field in TestConfiguration), so the connections would always be opened against the default database. I therefore made the test open all the connections in the main JUnit thread and pass the Connection objects as arguments to the helper threads when creating them.

          With this patch, the time to run BlobClob4BlobTest was reduced from 5 min 25 sec to 1 min 40 sec in my environment. (No change in run time for DeadlockModeTest since it doesn't usually see lock timeouts.)

          Show
          Knut Anders Hatlen added a comment - Here's a second patch that makes BlobClob4BlobTest and DeadlockModeTest use the reduced timeouts when running against encrypted databases. The patch changes the order of the decorators so that the DatabasePropertyTestSetup executes inside the encryption decorator, and this ensures that it works on the encrypted database instead of on the default database. DeadlockModeTest had one more problem that needed to be fixed. The encrypted variant always worked on the default (non-encrypted) database, not only when setting the timeouts, but also when doing database operations in the test case. The reason for this was that all the database connections were opened in helper threads, and the decorators only change the test configuration for the current thread (in a thread local field in TestConfiguration), so the connections would always be opened against the default database. I therefore made the test open all the connections in the main JUnit thread and pass the Connection objects as arguments to the helper threads when creating them. With this patch, the time to run BlobClob4BlobTest was reduced from 5 min 25 sec to 1 min 40 sec in my environment. (No change in run time for DeadlockModeTest since it doesn't usually see lock timeouts.)
          Hide
          Knut Anders Hatlen added a comment -

          Committed revision 1032907.

          Show
          Knut Anders Hatlen added a comment - Committed revision 1032907.

            People

            • Assignee:
              Knut Anders Hatlen
              Reporter:
              Knut Anders Hatlen
            • Votes:
              0 Vote for this issue
              Watchers:
              0 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development