db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jeremy Boynes <jboy...@apache.org>
Subject Re: Support multiple Derby systems in one VM
Date Thu, 24 Nov 2005 16:37:43 GMT
This seems similar (at least in my head) to DataSourceFactory here:
http://mail-archives.apache.org/mod_mbox/db-derby-user/200511.mbox/browser

As Dan said, I think we need to be careful not to confuse the two
mechanisms for setting properties. However, I think there is a clear
separation between properties used to configure an engine and those used
to configure a datasource used to access the engine:

* properties on DerbySystem/DataSourceFactory that are used to configure
  the underlying engine itself (such as location of the error log)
* properties on the DataSource implementation that configure how the
  user is going to connect to that engine

In DataSourceFactory, the getFactory() method took a uri that identified
the desired implementation. The resulting factory could then be
configured with implementation specific properties (in Derby's case,
engine properties) before being used to create a DataSource. The
resulting DataSource can then be configured as usual.

For example,

DataSourceFactory systemA = DataSourceFactory.getFactory("derby:10.2");
DataSourceFactory systemB = DataSourceFactory.getFactory("derby:11.1");

systemA.setProperty("derby.system.home", "/home/dbA");
systemA.setProperty("derby.error.log", "/home/dbA/derby.log");

systemB.setProperty("derby.system.home", "/home/dbB");
systemB.setProperty("derby.error.log", "/home/dbB/foo.log");

DataSource dsA = systemA.getDataSource();
DataSource dsB = systemB.getDataSource();

BeanUtils.setProperty(dsA, "databaseName", "wombat");
Connection connA = dsA.getConnection();

BeanUtils.setProperty(dsB, "databaseName", "wombat");
Connection connB = dsB.getConnection();

--
Jeremy

David W. Van Couvering wrote:
> 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


Mime
View raw message