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: Multiple engines in same JVM
Date Thu, 21 Jul 2005 15:50:33 GMT
David Van Couvering wrote:
> 
> 
> Jeremy Boynes wrote:
> 
> [snip]
> 
>>
>>
>> AIUI there are two levels of configuration: system and database
>> * system configuration comes from system properties and
>>   classloader resources
>> * database configuration overrides based on values from derby.properties
>>   in the database directory
> 
> 
> My investigation says there are three levels:
> - System properties set through the command line or programmatically
> - Database properties
> - Properties set in derby.properties
> 
> What do you mean by "classloader resources?"
> 

I meant things loaded as resources such as modules.properties
These come from the codebase (the jar files) not from the environment 
(properties or the disk image of the db)

<snip/>
> 
> Finally, the derby.properties file for a system must be located in the 
> directory specified by derby.system.home system property.  So again 
> there is no way to have more than one system configuration per VM, as 
> far as I can tell.
> 
> It seems to me this could be easily fixed in the following way:
> 
> - derby.properties is loaded by the classloader
> - derby.system.home can be specified in derby.properties
> 
> This would allow you to have multiple Derby system instances in the same 
> VM, right?  Is that what you meant by a "per-classloader static property 
> map" below?
> 

I meant that rather than looking up property values from 
java.lang.System it would be simple to modify the code to use a 
PropertyManager that would keep the properties in a static. Given 
statics are local to the ClassLoader, different versions of the engine 
loaded by different ClassLoader's would have different properties.

There would need to be a way to initially populate each copy of the map; 
for simple installations it could work as now by cloning the system 
properties, for more complex installations some other mechanism could be 
used (e.g. config-values in ra.xml if the engine was deployed as a 
ResourceAdapter).

I don't think loading from the codebase using ClassLoader.getResource() 
(as is done for modules.properties) will be flexible enough; I wasn't 
sure if that is what you meant by "loaded by the classloader"

<snip/>

>>
>> I have also wondered about providing an injection mechanism for stored 
>> procedure implementations where the engine would inject a DataSource 
>> into the class or instance that could be used instead of DriverManager 
>> to obtain the connection. This is obviously an extension to the spec 
>> but  might be friendlier.
>>
> 
> Using a DataSource does sound friendlier, but it is an "extension" as 
> you say.  And one of the "prime directives" of Derby as I understand it 
> is to stay with the standards, so that migration to "other databases" is 
> possible and customers feel they aren't locked in.  How would you 
> reconcile this?
> 

 From my perspective, if there is a standard way of doing something then 
we should implement it. If there are limitations with the standard 
approach that we can improve then we add extensions. The standards 
define the lowest common denominator that users can use to ensure 
portability; extensions provide benefit to users at the cost of 
potential lock in. Let people choose how much lock they want.

--
Jeremy


Mime
View raw message