Derby
  1. Derby
  2. DERBY-930

Add support for autoloading of Derby client drivers

    Details

    • Type: Improvement Improvement
    • Status: Closed
    • Priority: Major Major
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 10.2.1.6
    • Component/s: Build tools, JDBC
    • Labels:
      None

      Description

      Write Derby's driver names into the correct spot in derby.jar and derbyclient.jar so that the 1.6 vm autoloads Derby drivers. Section 10.2.1 of the JDBC4 spec describes the details.

      1. autoloading_scenarios.html
        5 kB
        Kathey Marsden
      2. bug930_problem.diff
        20 kB
        Rick Hillegas
      3. bug930_problem2.diff
        24 kB
        Rick Hillegas
      4. bug930_rev2.diff
        15 kB
        Rick Hillegas
      5. bug930_rev3.diff
        16 kB
        Rick Hillegas
      6. bug930.diff
        28 kB
        Rick Hillegas
      7. ClassloadingTest.jar
        6 kB
        Rick Hillegas

        Issue Links

          Activity

          Rick Hillegas created issue -
          Rick Hillegas made changes -
          Field Original Value New Value
          Assignee Rick Hillegas [ rhillegas ]
          Hide
          Rick Hillegas added a comment -

          This patch makes the jar building targets stuff a) derby.jar with the embedded driver name and b) derbyclient.jar with the client driver name. Some details follow:

          o trunk/build.xml - Created a single target for making the META-INF directory. Previously, this logic was cut-and-pasted across the jarring targets.

          o trunk/build.xml - Added logic to create META-INF/services/java.sql.Driver files to derby.jar and derbyclient.jar

          o AutoloadTest.java - New test to verify that the Derby drivers autoload when run from our jar files.

          I disabled the security manager for AutoloadTest. The reasons for this are documented in AutoloadTest_app.properties: When running under our test harness from jar files under jdk1.6, system properties can't be read. This causes the drivers to silently fail to autoload. Note that when running under jdk1.6 from jar files outside our test harness, the drivers correctly autoload.

          The new test is wired into the jdbc4 suite. The suite runs cleanly under 1.6 against the class tree and against the Derby jar files. The test itself runs cleanly embedded and with the Derby client under 1.6 and 1.4 and against the class tree and the jar files.

          Here are the patch contents:

          A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi
          A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi\AutoloadTest_app.properties
          A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi\AutoloadTest.java
          A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi\build.xml
          M java\testing\org\apache\derbyTesting\functionTests\suites\jdbc4.runall
          M java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java
          M java\testing\org\apache\derbyTesting\functionTests\util\derby_tests.policy
          M java\testing\build.xml
          M build.xml

          Show
          Rick Hillegas added a comment - This patch makes the jar building targets stuff a) derby.jar with the embedded driver name and b) derbyclient.jar with the client driver name. Some details follow: o trunk/build.xml - Created a single target for making the META-INF directory. Previously, this logic was cut-and-pasted across the jarring targets. o trunk/build.xml - Added logic to create META-INF/services/java.sql.Driver files to derby.jar and derbyclient.jar o AutoloadTest.java - New test to verify that the Derby drivers autoload when run from our jar files. I disabled the security manager for AutoloadTest. The reasons for this are documented in AutoloadTest_app.properties: When running under our test harness from jar files under jdk1.6, system properties can't be read. This causes the drivers to silently fail to autoload. Note that when running under jdk1.6 from jar files outside our test harness, the drivers correctly autoload. The new test is wired into the jdbc4 suite. The suite runs cleanly under 1.6 against the class tree and against the Derby jar files. The test itself runs cleanly embedded and with the Derby client under 1.6 and 1.4 and against the class tree and the jar files. Here are the patch contents: A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi\AutoloadTest_app.properties A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi\AutoloadTest.java A java\testing\org\apache\derbyTesting\functionTests\tests\junitTests\jdbcapi\build.xml M java\testing\org\apache\derbyTesting\functionTests\suites\jdbc4.runall M java\testing\org\apache\derbyTesting\functionTests\util\DerbyJUnitTest.java M java\testing\org\apache\derbyTesting\functionTests\util\derby_tests.policy M java\testing\build.xml M build.xml
          Rick Hillegas made changes -
          Attachment bug930.diff [ 12322712 ]
          Hide
          Daniel John Debrunner added a comment -

          In the policy file the patch has lines like:

          + // junitTests/jdbcapi/AutoloadTest.java
          + permission java.lang.RuntimePermission "getProtectionDomain";

          but this permission is for generic code in DerbyJUnitTest, not just that specific test.

          When the test runs with JDK 1.4 is it auto-loading the driver? I couldn't see any setting of jdbc.drivers so I'm unclear what would cause the driver to auto-load.

          From earlier comment:
          > I disabled the security manager for AutoloadTest. The reasons for this are documented in AutoloadTest_app.properties: When running under our test harness from jar files under jdk1.6, system properties can't be read. This causes the drivers to silently fail to autoload. Note that when running under jdk1.6 from jar files outside our test harness, the drivers correctly autoload.

          This is somewhat troubling, I don't understand what reading system properties has to do with the auto-loading of JDBC drivers by the java virtual machine. Can you maybe explain more why this fails for you, rather than just disabling the security manager. Disabling the security manager should not be a common option. I think it's as simple as you are not fetching the System property in a priv block.

          Show
          Daniel John Debrunner added a comment - In the policy file the patch has lines like: + // junitTests/jdbcapi/AutoloadTest.java + permission java.lang.RuntimePermission "getProtectionDomain"; but this permission is for generic code in DerbyJUnitTest, not just that specific test. When the test runs with JDK 1.4 is it auto-loading the driver? I couldn't see any setting of jdbc.drivers so I'm unclear what would cause the driver to auto-load. From earlier comment: > I disabled the security manager for AutoloadTest. The reasons for this are documented in AutoloadTest_app.properties: When running under our test harness from jar files under jdk1.6, system properties can't be read. This causes the drivers to silently fail to autoload. Note that when running under jdk1.6 from jar files outside our test harness, the drivers correctly autoload. This is somewhat troubling, I don't understand what reading system properties has to do with the auto-loading of JDBC drivers by the java virtual machine. Can you maybe explain more why this fails for you, rather than just disabling the security manager. Disabling the security manager should not be a common option. I think it's as simple as you are not fetching the System property in a priv block.
          Hide
          Rick Hillegas added a comment -

          Thanks for your quick review, Dan. Some responses follow:

          1) I'll change the comments in the policy file to note that the code is generic to DerbyJUnitTest

          2) I was simply testing the autoloading added by JDBC4. You are right that setting jdbc.drivers under JDBC3 should cause autoloading too. I will add the AutoloadTest to the jdk1.4 suite while setting jdbc.drivers appropriately.

          3) I will investigate wrapping the property reader in a priv block to see if this fixes the permissions problem. I may have to ask you for more advice here before I touch bottom.

          Show
          Rick Hillegas added a comment - Thanks for your quick review, Dan. Some responses follow: 1) I'll change the comments in the policy file to note that the code is generic to DerbyJUnitTest 2) I was simply testing the autoloading added by JDBC4. You are right that setting jdbc.drivers under JDBC3 should cause autoloading too. I will add the AutoloadTest to the jdk1.4 suite while setting jdbc.drivers appropriately. 3) I will investigate wrapping the property reader in a priv block to see if this fixes the permissions problem. I may have to ask you for more advice here before I touch bottom.
          Hide
          Rick Hillegas added a comment -

          I have attached bug930_problem.diff, which demonstrates the problem I am having autoloading Derby drivers under a SecurityManager. The problem case contains the following files:

          A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\AutoloadDriver.java
          A autoloadscript
          M build.xml
          A autoload.policy

          Once you have applied this patch to a clean client, you can reproduce the problem by invoking the script from the directory above trunk:

          trunk/autoloadscript

          Show
          Rick Hillegas added a comment - I have attached bug930_problem.diff, which demonstrates the problem I am having autoloading Derby drivers under a SecurityManager. The problem case contains the following files: A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\AutoloadDriver.java A autoloadscript M build.xml A autoload.policy Once you have applied this patch to a clean client, you can reproduce the problem by invoking the script from the directory above trunk: trunk/autoloadscript
          Rick Hillegas made changes -
          Attachment bug930_problem.diff [ 12322775 ]
          Hide
          Andrew McIntyre added a comment -

          Looks good, the getCodeSource method looks like it could be reused in sysinfo to take care of DERBY-668, among others, although I don't know if adding the getProtectionDomain permission would be a serious drawback. Dan could probably answer that question.

          Just a couple of minor cleanliness nits: Instead of creating a second section for jar helper targets, could you please move the new common targets to the section 'jar helper targets'? And why did you add dashes to the target names for the new common targets? It's ok, just out of convention with the rest of the target names in the main build.xml.

          I'll take a look at the problem when i have a moment and see if i can help.

          Show
          Andrew McIntyre added a comment - Looks good, the getCodeSource method looks like it could be reused in sysinfo to take care of DERBY-668 , among others, although I don't know if adding the getProtectionDomain permission would be a serious drawback. Dan could probably answer that question. Just a couple of minor cleanliness nits: Instead of creating a second section for jar helper targets, could you please move the new common targets to the section 'jar helper targets'? And why did you add dashes to the target names for the new common targets? It's ok, just out of convention with the rest of the target names in the main build.xml. I'll take a look at the problem when i have a moment and see if i can help.
          Hide
          Rick Hillegas added a comment -

          Thanks for the review, Andrew. I will airbrush build.xml as you requested. The dashes in the new target names are a convention I brought from a previous life: they are a prefix I'm used to putting on targets which are for internal use only (not to be called directly by the user who invokes ant). I can remove the dashes if they seem out of place.

          This patch is, of course, not ready for committing. I have to resolve the SecurityManager problem before I submit a new patch.

          Regards,
          -Rick

          Show
          Rick Hillegas added a comment - Thanks for the review, Andrew. I will airbrush build.xml as you requested. The dashes in the new target names are a convention I brought from a previous life: they are a prefix I'm used to putting on targets which are for internal use only (not to be called directly by the user who invokes ant). I can remove the dashes if they seem out of place. This patch is, of course, not ready for committing. I have to resolve the SecurityManager problem before I submit a new patch. Regards, -Rick
          Hide
          Rick Hillegas added a comment -

          The next attachment (bug930_problem2.diff) shows that the problem is not in Derby's drivers. The problem occurs with a DummyDriver which prints out some diagnostics. Without a SecurityManager, Class.forName() is called on the autoloadable drivers under DriverManager.getConnection(). However, we never get to this Class.forName() when there is a SecurityManager. The contents of this problem case are:

          A java\engine\org\apache\derby\jdbc\DummyDriver.java
          M java\engine\org\apache\derby\jdbc\build.xml
          A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\AutoloadDriver.java
          A autoloadscript
          M build.xml
          M tools\jar\extraDBMSclasses.properties
          A autoload.policy

          When there is a SecurityManager, the following invocation of Class.forName() is not reached:

          java.lang.Throwable: static initializer trace
          at org.apache.derby.jdbc.DummyDriver.<clinit>(DummyDriver.java:14)
          at java.lang.Class.forName0(Native Method)
          at java.lang.Class.forName(Class.java:247)
          at sun.misc.Service$LazyIterator.next(Service.java:271)
          at java.sql.DriverManager.loadInitialDrivers(DriverManager.java:477)
          at java.sql.DriverManager.initialize(DriverManager.java:579)
          at java.sql.DriverManager.getConnection(DriverManager.java:532)
          at java.sql.DriverManager.getConnection(DriverManager.java:150)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadDriver.getConnection(AutoloadDriver.java:80)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadDriver.execute(AutoloadDriver.java:52)
          at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadDriver.main(AutoloadDriver.java:41)

          Show
          Rick Hillegas added a comment - The next attachment (bug930_problem2.diff) shows that the problem is not in Derby's drivers. The problem occurs with a DummyDriver which prints out some diagnostics. Without a SecurityManager, Class.forName() is called on the autoloadable drivers under DriverManager.getConnection(). However, we never get to this Class.forName() when there is a SecurityManager. The contents of this problem case are: A java\engine\org\apache\derby\jdbc\DummyDriver.java M java\engine\org\apache\derby\jdbc\build.xml A java\testing\org\apache\derbyTesting\functionTests\tests\jdbcapi\AutoloadDriver.java A autoloadscript M build.xml M tools\jar\extraDBMSclasses.properties A autoload.policy When there is a SecurityManager, the following invocation of Class.forName() is not reached: java.lang.Throwable: static initializer trace at org.apache.derby.jdbc.DummyDriver.<clinit>(DummyDriver.java:14) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at sun.misc.Service$LazyIterator.next(Service.java:271) at java.sql.DriverManager.loadInitialDrivers(DriverManager.java:477) at java.sql.DriverManager.initialize(DriverManager.java:579) at java.sql.DriverManager.getConnection(DriverManager.java:532) at java.sql.DriverManager.getConnection(DriverManager.java:150) at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadDriver.getConnection(AutoloadDriver.java:80) at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadDriver.execute(AutoloadDriver.java:52) at org.apache.derbyTesting.functionTests.tests.jdbcapi.AutoloadDriver.main(AutoloadDriver.java:41)
          Rick Hillegas made changes -
          Attachment bug930_problem2.diff [ 12322815 ]
          Hide
          Rick Hillegas added a comment -

          I have attached a jarred up experiment which demonstrates a SecurityManager-induced classloading issue which results in the silent failure to autoload the jdbc driver. The autoloading logic is using the thread context class loader to look in the classpath for all resources with the name META-INF/services/java.sql.Driver. If you run with a SecurityManager, the thread context class loader only finds one META-INF/services/java.sql.Driver, namely, the one in the jar file which contains the calling code. However, if you don't run with a SecurityManager, then the thread context class loader finds many META-INF/services/java.sql.Driver(s), one in each jar file on the classpath.

          The experiment contains the following files:

          o A.jar - Jar file holding the calling program and its own META-INF/services/java.sql.Driver
          o B.jar - Jar file containing another META-INF/services/java.sql.Driver
          o AB.policy - Security policy for both jar files
          o autoloadslim - Driving script which runs the application both with and without a SecurityManager
          o AutoloadClassloader.java - The application which looks for META-INF/services/java.sql.Driver using the thread context class loader

          Show
          Rick Hillegas added a comment - I have attached a jarred up experiment which demonstrates a SecurityManager-induced classloading issue which results in the silent failure to autoload the jdbc driver. The autoloading logic is using the thread context class loader to look in the classpath for all resources with the name META-INF/services/java.sql.Driver. If you run with a SecurityManager, the thread context class loader only finds one META-INF/services/java.sql.Driver, namely, the one in the jar file which contains the calling code. However, if you don't run with a SecurityManager, then the thread context class loader finds many META-INF/services/java.sql.Driver(s), one in each jar file on the classpath. The experiment contains the following files: o A.jar - Jar file holding the calling program and its own META-INF/services/java.sql.Driver o B.jar - Jar file containing another META-INF/services/java.sql.Driver o AB.policy - Security policy for both jar files o autoloadslim - Driving script which runs the application both with and without a SecurityManager o AutoloadClassloader.java - The application which looks for META-INF/services/java.sql.Driver using the thread context class loader
          Rick Hillegas made changes -
          Attachment ClassloadingTest.jar [ 12323471 ]
          Hide
          Rick Hillegas added a comment -

          I have attached a revised patch for this feature: bug930_rev2.diff. This patch cannot be committed until mustang build 81 posts. That build should fix a jdk bug which short-circuits driver autoloading when running under a SecurityManager. This revised patch removes the need for the following permission when checking whether the test is running against the classtree or against jar files:

          permission java.lang.RuntimePermission "getProtectionDomain";

          This patch touches the following files:

          A java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\AutoloadTest.java
          M java\testing\org\apache\derbyTesting\functionTests\suites\jdbc40.runall
          M java\testing\org\apache\derbyTesting\functionTests\util\TestConfiguration.java
          M java\testing\org\apache\derbyTesting\functionTests\util\BaseJDBCTestCase.java
          M build.xml

          I will re-run the jdbc4 tests against this patch once mustang build 81 posts.

          Show
          Rick Hillegas added a comment - I have attached a revised patch for this feature: bug930_rev2.diff. This patch cannot be committed until mustang build 81 posts. That build should fix a jdk bug which short-circuits driver autoloading when running under a SecurityManager. This revised patch removes the need for the following permission when checking whether the test is running against the classtree or against jar files: permission java.lang.RuntimePermission "getProtectionDomain"; This patch touches the following files: A java\testing\org\apache\derbyTesting\functionTests\tests\jdbc4\AutoloadTest.java M java\testing\org\apache\derbyTesting\functionTests\suites\jdbc40.runall M java\testing\org\apache\derbyTesting\functionTests\util\TestConfiguration.java M java\testing\org\apache\derbyTesting\functionTests\util\BaseJDBCTestCase.java M build.xml I will re-run the jdbc4 tests against this patch once mustang build 81 posts.
          Rick Hillegas made changes -
          Attachment bug930_rev2.diff [ 12325156 ]
          Mike Matrigali made changes -
          Component/s Build tools [ 11405 ]
          Component/s JDBC [ 11407 ]
          Hide
          Rick Hillegas added a comment -

          Attaching bug930_rev3.diff, which makes a small change to the test for whether we're running with jar files. Build 81 of jdk1.6 fixes the problem with autoloading under a SecurityManager. The AutoloadTest now runs correctly.

          Show
          Rick Hillegas added a comment - Attaching bug930_rev3.diff, which makes a small change to the test for whether we're running with jar files. Build 81 of jdk1.6 fixes the problem with autoloading under a SecurityManager. The AutoloadTest now runs correctly.
          Rick Hillegas made changes -
          Attachment bug930_rev3.diff [ 12325777 ]
          Hide
          Rick Hillegas added a comment -

          Committed at subversion revision 396638. As of this submission, you need build 81 of jdk1.6 in order to run the jdbc4 tests cleanly.

          Show
          Rick Hillegas added a comment - Committed at subversion revision 396638. As of this submission, you need build 81 of jdk1.6 in order to run the jdbc4 tests cleanly.
          Hide
          Rick Hillegas added a comment -

          Fixed with build 81 of jdk1.6.

          Show
          Rick Hillegas added a comment - Fixed with build 81 of jdk1.6.
          Rick Hillegas made changes -
          Resolution Fixed [ 1 ]
          Status Open [ 1 ] Resolved [ 5 ]
          Fix Version/s 10.2.0.0 [ 11187 ]
          Rick Hillegas made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Hide
          Kathey Marsden added a comment -

          This change may impact existing applications as evidenced by the need to change a related test in DERBY-1399. It requires at least a release note documenting the impact. Once that has been done it will be easier understand the scope of the problem and whether this is a regression that needs to be addressed or a behaviour change accepted by the community.

          DERBY-1399 has some informaition on this topic.
          http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416359

          Rick, could you add the release note to this issue? Bryan posted some helpful Release Note format info at: http://wiki.apache.org/db-derby/ReleaseNoteFormat?highlight=%28ReleaseNote%29

          Show
          Kathey Marsden added a comment - This change may impact existing applications as evidenced by the need to change a related test in DERBY-1399 . It requires at least a release note documenting the impact. Once that has been done it will be easier understand the scope of the problem and whether this is a regression that needs to be addressed or a behaviour change accepted by the community. DERBY-1399 has some informaition on this topic. http://issues.apache.org/jira/browse/DERBY-1399?page=comments#action_12416359 Rick, could you add the release note to this issue? Bryan posted some helpful Release Note format info at: http://wiki.apache.org/db-derby/ReleaseNoteFormat?highlight=%28ReleaseNote%29
          Kathey Marsden made changes -
          Derby Info [Existing Application Impact, Release Note Needed]
          Hide
          Kathey Marsden added a comment -

          Reopened because at least release note is needed for behavior change.

          Show
          Kathey Marsden added a comment - Reopened because at least release note is needed for behavior change.
          Kathey Marsden made changes -
          Status Closed [ 6 ] Reopened [ 4 ]
          Resolution Fixed [ 1 ]
          Hide
          Rick Hillegas added a comment -

          I think that derby-dev should continue to discuss the issue which Olav has analyzed in DERBY-1399. I will continue this discussion shortly.

          Based on that discussion, we can decide what to put in a release note. It's unclear to me how to divide JDBC4 functionality among release notes. This issue may deserve a release not by itself, or it may be a subcase of some larger release note for JDBC4 features. But in any event, I agree we should attach some description to this issue for rollup somewhere in the 10.2 release notes.

          In addition, this behavior should be documented in the user guides. The analysis of user guide changes can be found in DERBY-1271.

          Show
          Rick Hillegas added a comment - I think that derby-dev should continue to discuss the issue which Olav has analyzed in DERBY-1399 . I will continue this discussion shortly. Based on that discussion, we can decide what to put in a release note. It's unclear to me how to divide JDBC4 functionality among release notes. This issue may deserve a release not by itself, or it may be a subcase of some larger release note for JDBC4 features. But in any event, I agree we should attach some description to this issue for rollup somewhere in the 10.2 release notes. In addition, this behavior should be documented in the user guides. The analysis of user guide changes can be found in DERBY-1271 .
          Rick Hillegas made changes -
          Link This issue is related to DERBY-1429 [ DERBY-1429 ]
          Hide
          Rick Hillegas added a comment -

          Adding a release note for this issue:

          PROBLEM

          If an embedded Derby application generates its own Derby properties on the fly, and that Derby application runs in the same VM with other JDBC applications, then you are not guaranteed that the Derby engine will pick up the custom properties when it boots.

          SYMPTOM

          Derby startup behavior will be non-deterministic. Sometimes the engine will pick up the custom properties and sometimes it won't.

          CAUSE

          JDBC4 introduced driver-autoloading. This causes all JDBC drivers visible to the VM to register themselves the first time some application requests a Connection. When the embedded Derby driver registers itself, it also boots the Derby engine and the engine picks up whatever Derby properties are currently visible. An embedded Derby application may want to configure the engine properties before asking for a Connection. That embedded Derby application will not get a chance to configure engine properties if some other JDBC application in the same VM runs first and requests a Connection. Two related bugs describe this issue in greater detail: DERBY-1428 and DERBY-1429.

          SOLUTION

          There is no general solution to the problem. If two self-configuring embedded Derby applications run in the same VM, then only one of them can win.

          WORKAROUND

          The following workarounds may be useful:

          1) Don't configure Derby properties inside your applications. Instead, specify Derby properties either on the VM startup line or in a $DERBY_HOME/derby.properties which remains constant for the VM's lifetime.

          2) If (1) is not possible, then make the self-configuring Derby application run first.

          Show
          Rick Hillegas added a comment - Adding a release note for this issue: PROBLEM If an embedded Derby application generates its own Derby properties on the fly, and that Derby application runs in the same VM with other JDBC applications, then you are not guaranteed that the Derby engine will pick up the custom properties when it boots. SYMPTOM Derby startup behavior will be non-deterministic. Sometimes the engine will pick up the custom properties and sometimes it won't. CAUSE JDBC4 introduced driver-autoloading. This causes all JDBC drivers visible to the VM to register themselves the first time some application requests a Connection. When the embedded Derby driver registers itself, it also boots the Derby engine and the engine picks up whatever Derby properties are currently visible. An embedded Derby application may want to configure the engine properties before asking for a Connection. That embedded Derby application will not get a chance to configure engine properties if some other JDBC application in the same VM runs first and requests a Connection. Two related bugs describe this issue in greater detail: DERBY-1428 and DERBY-1429 . SOLUTION There is no general solution to the problem. If two self-configuring embedded Derby applications run in the same VM, then only one of them can win. WORKAROUND The following workarounds may be useful: 1) Don't configure Derby properties inside your applications. Instead, specify Derby properties either on the VM startup line or in a $DERBY_HOME/derby.properties which remains constant for the VM's lifetime. 2) If (1) is not possible, then make the self-configuring Derby application run first.
          Rick Hillegas made changes -
          Derby Info [Existing Application Impact, Release Note Needed] [Existing Application Impact, Regression, Release Note Needed]
          Hide
          Rick Hillegas added a comment -

          Here is a second rev of the release note. This attempts to clarify the extra exposure introduced by jdk1.6.

          PROBLEM

          If an embedded Derby application generates its own Derby properties on the fly, and that Derby application runs in the same 1.6 VM with other JDBC applications, then you are not guaranteed that the Derby engine will pick up the custom properties when it boots.

          SYMPTOM

          Derby startup behavior will be non-deterministic. Sometimes the engine will pick up the custom properties and sometimes it won't.

          CAUSE

          JDBC4 introduced driver-autoloading. This causes all JDBC drivers visible to the 1.6 VM to register themselves the first time some application requests a Connection. When the embedded Derby driver registers itself, it also boots the Derby engine and the engine picks up whatever Derby properties are currently visible. An embedded Derby application may want to configure the engine properties before asking for a Connection. That embedded Derby application will not get a chance to configure engine properties if some other JDBC application in the same 1.6 VM runs first and requests a Connection. Two related bugs describe this issue in greater detail: DERBY-1428 and DERBY-1429. DERBY-1428 affects existing customer installations running old versions of Derby on the 1.3, 1.4, and 1.5 VMs. DERBY-1429 describes the extra exposure introduced with the 1.6 VM.

          SOLUTION

          There is no general solution to the problem. If two self-configuring embedded Derby applications run in the same VM, then only one of them can win.

          WORKAROUND

          The following workarounds may be useful:

          1) Don't configure Derby properties inside your applications. Instead, specify Derby properties either on the VM startup line or in a $DERBY_HOME/derby.properties which remains constant for the VM's lifetime.

          2) Don't run on the 1.6 VM. This eliminates the problem provided that you are not running more than one embedded Derby application in the same VM.

          3) If (1) and (2) are not possible, then make the self-configuring Derby application run first.

          Show
          Rick Hillegas added a comment - Here is a second rev of the release note. This attempts to clarify the extra exposure introduced by jdk1.6. PROBLEM If an embedded Derby application generates its own Derby properties on the fly, and that Derby application runs in the same 1.6 VM with other JDBC applications, then you are not guaranteed that the Derby engine will pick up the custom properties when it boots. SYMPTOM Derby startup behavior will be non-deterministic. Sometimes the engine will pick up the custom properties and sometimes it won't. CAUSE JDBC4 introduced driver-autoloading. This causes all JDBC drivers visible to the 1.6 VM to register themselves the first time some application requests a Connection. When the embedded Derby driver registers itself, it also boots the Derby engine and the engine picks up whatever Derby properties are currently visible. An embedded Derby application may want to configure the engine properties before asking for a Connection. That embedded Derby application will not get a chance to configure engine properties if some other JDBC application in the same 1.6 VM runs first and requests a Connection. Two related bugs describe this issue in greater detail: DERBY-1428 and DERBY-1429 . DERBY-1428 affects existing customer installations running old versions of Derby on the 1.3, 1.4, and 1.5 VMs. DERBY-1429 describes the extra exposure introduced with the 1.6 VM. SOLUTION There is no general solution to the problem. If two self-configuring embedded Derby applications run in the same VM, then only one of them can win. WORKAROUND The following workarounds may be useful: 1) Don't configure Derby properties inside your applications. Instead, specify Derby properties either on the VM startup line or in a $DERBY_HOME/derby.properties which remains constant for the VM's lifetime. 2) Don't run on the 1.6 VM. This eliminates the problem provided that you are not running more than one embedded Derby application in the same VM. 3) If (1) and (2) are not possible, then make the self-configuring Derby application run first.
          Hide
          Kathey Marsden added a comment -

          The attached document autoloading_scenarios.html has three scenarios that need to be considered for our autoloading implementation. Scenario's #1 and #3 have regressions with our current implementation. Scenario #2 will regress if we move processing of derby.drda.startNetworkServer to connection time.

          Show
          Kathey Marsden added a comment - The attached document autoloading_scenarios.html has three scenarios that need to be considered for our autoloading implementation. Scenario's #1 and #3 have regressions with our current implementation. Scenario #2 will regress if we move processing of derby.drda.startNetworkServer to connection time.
          Kathey Marsden made changes -
          Attachment autoloading_scenarios.html [ 12335878 ]
          Kathey Marsden made changes -
          Link This issue relates to DERBY-1459 [ DERBY-1459 ]
          Hide
          Kathey Marsden added a comment -

          DERBY-1459 is logged for the regression caused by this fix, so unchecking the regression checkbox.

          Show
          Kathey Marsden added a comment - DERBY-1459 is logged for the regression caused by this fix, so unchecking the regression checkbox.
          Kathey Marsden made changes -
          Derby Info [Regression, Existing Application Impact, Release Note Needed] [Existing Application Impact, Release Note Needed]
          Hide
          Rick Hillegas added a comment -

          Closing this issue because DERBY-1459 addresses the problem.

          Show
          Rick Hillegas added a comment - Closing this issue because DERBY-1459 addresses the problem.
          Rick Hillegas made changes -
          Resolution Fixed [ 1 ]
          Status Reopened [ 4 ] Closed [ 6 ]
          Derby Info [Release Note Needed, Existing Application Impact] [Existing Application Impact, Release Note Needed]
          Rick Hillegas made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Rick Hillegas added a comment -

          Since this issue was fixed, no release note is needed.

          Show
          Rick Hillegas added a comment - Since this issue was fixed, no release note is needed.
          Rick Hillegas made changes -
          Derby Info [Existing Application Impact, Release Note Needed] [Existing Application Impact]
          Rick Hillegas made changes -
          Status Reopened [ 4 ] Closed [ 6 ]
          Resolution Fixed [ 1 ]
          Hide
          Daniel John Debrunner added a comment -

          With this issue it seems that the changes made to auto-loading (the two stages) means that the Existing Application Impact flag should be unchecked.

          Show
          Daniel John Debrunner added a comment - With this issue it seems that the changes made to auto-loading (the two stages) means that the Existing Application Impact flag should be unchecked.
          Rick Hillegas made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Rick Hillegas made changes -
          Derby Info [Existing Application Impact]
          Rick Hillegas made changes -
          Resolution Fixed [ 1 ]
          Status Reopened [ 4 ] Closed [ 6 ]
          Dag H. Wanvik made changes -
          Issue Type New Feature [ 2 ] Improvement [ 4 ]
          Gavin made changes -
          Workflow jira [ 12346762 ] Default workflow, editable Closed status [ 12798313 ]
          Transition Time In Source Status Execution Times Last Executer Last Execution Date
          Open Open Resolved Resolved
          75d 23h 31m 1 Rick Hillegas 25/Apr/06 04:09
          Resolved Resolved Closed Closed
          17s 1 Rick Hillegas 25/Apr/06 04:09
          Closed Closed Reopened Reopened
          268d 22h 4m 3 Rick Hillegas 22/Feb/07 19:46
          Reopened Reopened Closed Closed
          34d 18h 32m 3 Rick Hillegas 22/Feb/07 19:46

            People

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

              Dates

              • Created:
                Updated:
                Resolved:

                Development