db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Support multiple Derby systems in one VM
Date Thu, 24 Nov 2005 00:44:14 GMT
I get your point that we don't want to have one classloader per data 
source, and we should use the default wherever possible.

I don't think we should depend on Env properties (I'm assuming you mean 
"java:comp/env" properties) because these are available only in J2EE 

A data source has properties on it, two of them could be 
derby.system.home and derby.system.classpath.  If derby.system.classpath 
is not set then we could just use the default classloader (or perhaps 
the one that prevents shadowing that I am considering) to load derby 

Just thoughts at this point.  All this needs to be demonstrated with 
working code...


Francois Orsini wrote:
> 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 created...
> Does this make any sense at all...?
> --francois
> On 11/23/05, *Daniel John Debrunner* < djd@debrunners.com 
> <mailto: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