I also wanted to share an idea to help move us towards the larger
problem supporting multiple Derby systems within the same VM (currently
that's not possible).
The idea is that we have a new public class called DerbySystem that's in
it's own package. This is basically a data source factory for a given
Derby system, each with its own classloader. So in the same VM I could
do something like
// Note the properties could be loaded from a config file rather
// than hardcoded in the source
Properties propsA = new Properties();
propsA.setProperty("derby.system.home", "/path/to/system/a");
propsA.setProperty("derby.system.classpath",
"/home/derby/10.1/derby.jar");
DerbySystem systemA = new DerbySystem(propsA);
Properties propsB = new Properties();
propsB.setProperty("derby.system.home", "/path/to/system/b");
propsA.setProperty("derby.system.classpath", "/home/derby/10.2/derby.jar");
DerbySystem systemB = new DerbySystem(propsB);
DataSource dsA = systemA.getDataSource("jdbc:derby:wombat;create=true");
DataSource dsB = systemB.getDataSource("jdbc:derby:wombat;create=true");
Connection connA = dsA.getConnection();
Connection connB = dsB.getConnection();
Note that for this to really work we need to fix Derby so that there are
no hardcoded uses of system properties, but instead all code uses a
service to obtain configuration properties for a given system.
David
begin:vcard
fn:David W Van Couvering
n:Van Couvering;David W
org:Sun Microsystems, Inc.;Database Technology Group
email;internet:[EMAIL PROTECTED]
title:Senior Staff Software Engineer
tel;work:510-550-6819
tel;cell:510-684-7281
x-mozilla-html:TRUE
version:2.1
end:vcard
