db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: Support multiple Derby systems in one VM
Date Thu, 24 Nov 2005 00:06:28 GMT
Agreed - The challenge in this example is to separate the 2 properties set
upon instancing appropriate datasources...Fundamentally, 2 separate
classloaders have to be created - Obviously we would not want to have to
create a separate classloader everytime we instantiate a new DataSource,
except if we have a way/mechanism to find out that we need to do so (upon
instantiating an EmbeddedDataSource object for instance)...Upon
instantiating a specialized DataSource in derby, I wonder if it'd be
possible to detect from the environment (i.e. Env Properties) if anyhing
relevant has changed that would lead Derby to return the proper instantiated
DataSource object based on the environment (Env properties) - which means
that the DataSource Factory would have to be smart enough to figure this out
(keeping track of the  various Env Properties) in order to return the
appropriate one (off a new or existing classloader)...Now which properties
("derby.system.home", "derby.system.classpath" - is that enough?) would be
relevant enough to figure out that this DataSource should be instantiated in
a non-default classloader but one that is either known or yet to be

Does this make any sense at all...?


On 11/23/05, Daniel John Debrunner <djd@debrunners.com > wrote:
> However, it does seem to me that JDBC already provides two factory
> classes for getting connections, Driver and DataSource. Do we really
> need another factory api?
> Dan.

View raw message