Derby
  1. Derby
  2. DERBY-1228

Make it possible to run multiple instances of Derby within the same VM

    Details

    • Type: Improvement Improvement
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: None
    • Fix Version/s: None
    • Component/s: Services
    • Labels:
      None

      Description

      Make it possible to run multiple instances of Derby within the same VM, each with its own derby.system.home, separate configuration parameters, and even different versions of Derby jar files. I haven't looked at this carefully, but at first glance I think this would require (a) refactoring Derby code to get all configuration from a configuration API rather than directly from system properties (b) write a configuration API/class that supports a properties file as well as system properties (in the future this class could also work with JMX) (c) the ability to specify the derby.system.home and a classpath as a DataSource property (d) a Derby classloader that loads Derby jar files from the classpath specified on the DataSource

        Activity

        Hide
        Daniel John Debrunner added a comment -

        any testing could re-use the existing JUnit tests. It's fairly easy to write a junit test runner that ran two suites in diffferent class loaders, say one with 10.2 jars and one with 10.3 jars. Hardest item might be finding the sub-set of 10.3 tests that succeed against 10.2.
        In the future this would be easier as all releases will have a set of JUnit based tests that work against that release.

        On the jdbc driver class loader question, I don't think there are any problems. The visibility of drivers is restrictec, to quote the javadoc for DriverManager:

        "When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from amongst those loaded at initialization and those loaded explicitly using the same classloader as the current applet or application."

        That's what Derby wants, if app A is using Derby 10.3 in one class loader and app B using Derby 10.2 in another then they will see the version they require through DriverManager.

        I have a feeling though that the rule is not quite that simple, we have code that successfully gets a connection to "jdbc:default:connection" from classes loaded from installed jar files (which use their own classloader). I don't see how that fits in with the above statement.

        Show
        Daniel John Debrunner added a comment - any testing could re-use the existing JUnit tests. It's fairly easy to write a junit test runner that ran two suites in diffferent class loaders, say one with 10.2 jars and one with 10.3 jars. Hardest item might be finding the sub-set of 10.3 tests that succeed against 10.2. In the future this would be easier as all releases will have a set of JUnit based tests that work against that release. On the jdbc driver class loader question, I don't think there are any problems. The visibility of drivers is restrictec, to quote the javadoc for DriverManager: "When the method getConnection is called, the DriverManager will attempt to locate a suitable driver from amongst those loaded at initialization and those loaded explicitly using the same classloader as the current applet or application." That's what Derby wants, if app A is using Derby 10.3 in one class loader and app B using Derby 10.2 in another then they will see the version they require through DriverManager. I have a feeling though that the rule is not quite that simple, we have code that successfully gets a connection to "jdbc:default:connection" from classes loaded from installed jar files (which use their own classloader). I don't see how that fits in with the above statement.
        Hide
        Kathey Marsden added a comment -

        I think you are correct; an alternative to derby.system.home is the main
        issue. We need to provide an alternate way to specify the location for
        reading the properties file. Additionally, DERBY-700 would need to be
        fixed and we would need testing to make sure things like aggregates work
        with two instances of Derby loaded in the same jvm.

        Show
        Kathey Marsden added a comment - I think you are correct; an alternative to derby.system.home is the main issue. We need to provide an alternate way to specify the location for reading the properties file. Additionally, DERBY-700 would need to be fixed and we would need testing to make sure things like aggregates work with two instances of Derby loaded in the same jvm.
        Hide
        Mike Matrigali added a comment -

        Does anyone know if there is an issue with how jdbc drivers get booted in different classloaders?

        Show
        Mike Matrigali added a comment - Does anyone know if there is an issue with how jdbc drivers get booted in different classloaders?
        Hide
        Mike Matrigali added a comment -

        In the case where an appserver was already running multiple class loaders, would a solution which just addressed an alternate way to load thouse properties currently required to be system properties be sufficient? Would there be any need for special Derby classloaders or any new classpath handling? In this scenario it would be up to the application to insure the correct derby classpath for each different classloader loading a different version of derby.

        Show
        Mike Matrigali added a comment - In the case where an appserver was already running multiple class loaders, would a solution which just addressed an alternate way to load thouse properties currently required to be system properties be sufficient? Would there be any need for special Derby classloaders or any new classpath handling? In this scenario it would be up to the application to insure the correct derby classpath for each different classloader loading a different version of derby.
        Hide
        Gary Xue added a comment -

        I second this feature request. Not allowing multiple Derby system instances (and by extension, not allowing different versions of the Derby JAR files) to co-exist in the same JVM has now become a big headache for us working on the Eclipse projects. (Several Eclipse subprojects now use Derby).

        Derby would not become a viable solution for embedded database in a Server or Eclipse-based application unless this issue is resolved. It is impossible to require all extension or plugin providers to use the same (or compatible) versions of Derby.

        Show
        Gary Xue added a comment - I second this feature request. Not allowing multiple Derby system instances (and by extension, not allowing different versions of the Derby JAR files) to co-exist in the same JVM has now become a big headache for us working on the Eclipse projects. (Several Eclipse subprojects now use Derby). Derby would not become a viable solution for embedded database in a Server or Eclipse-based application unless this issue is resolved. It is impossible to require all extension or plugin providers to use the same (or compatible) versions of Derby.

          People

          • Assignee:
            Unassigned
            Reporter:
            David Van Couvering
          • Votes:
            4 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:

              Development