You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "David Van Couvering (JIRA)" <de...@db.apache.org> on 2006/04/19 20:47:36 UTC
[jira] Created: (DERBY-1228) Make it possible to run multiple
instances of Derby within the same VM
Make it possible to run multiple instances of Derby within the same VM
----------------------------------------------------------------------
Key: DERBY-1228
URL: http://issues.apache.org/jira/browse/DERBY-1228
Project: Derby
Type: New Feature
Reporter: David Van Couvering
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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1228) Make it possible to run multiple
instances of Derby within the same VM
Posted by "Kathey Marsden (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484516 ]
Kathey Marsden commented on DERBY-1228:
---------------------------------------
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.
> Make it possible to run multiple instances of Derby within the same VM
> ----------------------------------------------------------------------
>
> Key: DERBY-1228
> URL: https://issues.apache.org/jira/browse/DERBY-1228
> Project: Derby
> Issue Type: New Feature
> Components: Services
> Reporter: David Van Couvering
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (DERBY-1228) Make it possible to run multiple
instances of Derby within the same VM
Posted by "Daniel John Debrunner (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12484563 ]
Daniel John Debrunner commented on DERBY-1228:
----------------------------------------------
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.
> Make it possible to run multiple instances of Derby within the same VM
> ----------------------------------------------------------------------
>
> Key: DERBY-1228
> URL: https://issues.apache.org/jira/browse/DERBY-1228
> Project: Derby
> Issue Type: New Feature
> Components: Services
> Reporter: David Van Couvering
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1228) Make it possible to run multiple
instances of Derby within the same VM
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-1228:
----------------------------------
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.
> Make it possible to run multiple instances of Derby within the same VM
> ----------------------------------------------------------------------
>
> Key: DERBY-1228
> URL: https://issues.apache.org/jira/browse/DERBY-1228
> Project: Derby
> Issue Type: New Feature
> Components: Services
> Reporter: David Van Couvering
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1228) Make it possible to run multiple
instances of Derby within the same VM
Posted by "Mike Matrigali (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/DERBY-1228?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Mike Matrigali updated DERBY-1228:
----------------------------------
Does anyone know if there is an issue with how jdbc drivers get booted in different classloaders?
> Make it possible to run multiple instances of Derby within the same VM
> ----------------------------------------------------------------------
>
> Key: DERBY-1228
> URL: https://issues.apache.org/jira/browse/DERBY-1228
> Project: Derby
> Issue Type: New Feature
> Components: Services
> Reporter: David Van Couvering
>
> 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
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (DERBY-1228) Make it possible to run multiple
instances of Derby within the same VM
Posted by "Kathey Marsden (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1228?page=all ]
Kathey Marsden updated DERBY-1228:
----------------------------------
Component: Services
> Make it possible to run multiple instances of Derby within the same VM
> ----------------------------------------------------------------------
>
> Key: DERBY-1228
> URL: http://issues.apache.org/jira/browse/DERBY-1228
> Project: Derby
> Type: New Feature
> Components: Services
> Reporter: David Van Couvering
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Commented: (DERBY-1228) Make it possible to run multiple
instances of Derby within the same VM
Posted by "Gary Xue (JIRA)" <de...@db.apache.org>.
[ http://issues.apache.org/jira/browse/DERBY-1228?page=comments#action_12416117 ]
Gary Xue commented on DERBY-1228:
---------------------------------
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.
> Make it possible to run multiple instances of Derby within the same VM
> ----------------------------------------------------------------------
>
> Key: DERBY-1228
> URL: http://issues.apache.org/jira/browse/DERBY-1228
> Project: Derby
> Type: New Feature
> Components: Services
> Reporter: David Van Couvering
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira