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

Details

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

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.

Gary Xue
added a comment - 14/Jun/06 11:50 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.

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.

Mike Matrigali
added a comment - 27/Mar/07 18:24 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.

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.

Kathey Marsden
added a comment - 27/Mar/07 18:43 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.

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.

Daniel John Debrunner
added a comment - 27/Mar/07 20:43 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.