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 Wed, 20 Jul 2005 22:23:23 GMT
David Van Couvering wrote:
> Jeremy Boynes wrote:
>> I would like to explore the possibility of running multiple Derby 
>> instances in the same JVM, probably in different classloaders.
> You use the term "Derby instance" but I'm not sure what you mean here.

I believe instance == system, my bad.

> Based on a discussion I had with Dan, a Derby "system" is the union of 
> all databases running under the same classloader.  Is that what you 
> mean?  Each system is supposed to have its own configuration.  But I had 
> trouble figuring out how to do this with multiple classloaders (see your 
> system properties discussion below), and nowhere do I see this tested 
> currently.

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

To locate the database directory (to get the derby.properties) you 
either need an absolute path for the database name, or the value of the 
derby.system.base system property

> I thought Dag, with Kathey's help, was able to configure things such 
> that you could have different Derby properties set for different 
> databases in the same VM.  Dag, how did that work again?
>> One use for that is an application server configuration where 
>> different applications may require different versions of Derby or 
>> where different instances may have different requirements e.g. for 
>> security.
>> 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.

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


View raw message