db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: Multiple engines in same JVM
Date Thu, 21 Jul 2005 00:19:22 GMT

Jeremy Boynes wrote:

> 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?"

Investigation of the Derby 10.1 Developer's Guide under the "Derby 
System" section shows a couple of things that indicate that there can 
only be one Derby system per VM, regardless of the number of 
classloaders. This is in conflict with what Dan had been telling me a 
"system" was:

"A Derby system is a single instance of the Derby database engine and 
the environment in which it runs. It consists of a system directory, 
zero or more databases, and a system-wide configuration. The system 
directory contains any persistent system-wide configuration parameters, 
or properties, specific to that system in a properties file called 

So I see "instance" and "system" are being used interchangeably.  Then 
further on it says:

"You could potentially have two instances of a Derby system (JVM) 
running on the same machine at the same time. Each instance must run in 
a different JVM."

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?

>>> Two big issues come to mind:
>>> 1) use of system properties
>>>    I would like to explore ways in which these can be replaced with a
>>>    per-instance configuration mechanism where each instance can have
>>>    separate properties. This could be as simple as a per-classloader
>>>    static property map but ideally something a little more flexible
>>>    would be useful


>> Well, I would love us moving to JMX.  It would solve a lot of problems 
>> around configuration for us, and it would also enable management by 
>> nice pretty GUIs, integration into larger systems managed by JMX (e.g. 
>> most app servers), etc.
>> I recognize this a change with system-wide impact which can not be 
>> taken upon lightly.  We'd also have to do it in a way that is 
>> pluggable, JMX is not something I expect is part of J2ME...
> I would like to see JMX instrumentation too but think it needs to be 
> layered on over the top of the component model rather than used as the 
> basis for it. We have MX4J available to support pre-Java5 JREs and it 
> may be possible to run that under a J2ME VM as well.

I agree, I wasn't arguing that JMX would replace our component model.  I 
had contemplated this for about 15 minutes but I quickly recognized our 
component model is much richer than what JMX provides.

>> X>
>>> 2) common touch point in DriverManager, especially for use within
>>>    stored procedures.
>>>    I think we can do something here with a special Driver implementation
>>>    that could handle multiple engine instances which I think makes this
>>>    related to David Van Couvering's common jar discussion.
>> I don't understand this point, could you explain further?
> The SQL standard Java binding says that a Java stored procedure can 
> retrieve a connection to its database by obtaining a connection to the 
> standard URL "jdbc:default:connection" from DriverManager. This sucks. 
> Especially in J2ME where you don't have a DriverManager.
> Derby supports this by registering a Driver that understands that URL 
> and which then retrieves the Connection from a thread local. We need to 
> make sure this implementation still works when multiple Drivers get 
> registered for the same URL from different engines. It should (I think) 
> if the internal Driver is registered from the engine's classloader.

> 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?



> -- 
> Jeremy

View raw message