Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Development" <derby-dev@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42795590.6020906@apache.org>
Date: Wed, 04 May 2005 16:06:56 -0700
From: Jeremy Boynes <jboynes@apache.org>
User-Agent: Mozilla Thunderbird 0.8 (Windows/20040913)
MIME-Version: 1.0
To: Derby Development <derby-dev@db.apache.org>
Subject: Re: Multiple systems in same VM -- does this really work?
References: <42794B51.9080804@sun.com>
In-Reply-To: <42794B51.9080804@sun.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

David Van Couvering wrote:
> Hi ,all.  I am getting questions we could use Derby inside a container 
> such that each application in the container could have its own separate 
> configuration.  In particular, it would be nice if each application 
> (which often has its own classloader) could store its database files in 
> a different location.
> 
> Based on previous discussions with Dan, my understanding is that 
> conceptually you can have multiple Derby systems in a VM if you have 
> each system created by a different classloader.  But since Derby system 
> -wide properties are set using Java system properties, I don't think 
> this could actually work.  Isn't it true that any  system-wide 
> configuration (done either through -D or through System.setProperty) 
> will apply for all Derby systems in the same VM?  Or does a system 
> property apply only for the classloader of the class calling 
> System.setProperty()?
> 
> Help here would be much appreciated.   I searched the Java SDK source 
> code, but the method to load properties is a native method, and I can't 
> find the native method source.  The fact that it *is* a native method, 
> however, makes me suspect that system properties are VM-wide and not 
> just classloader-wide.
> 

We have the same issue embedding Derby in Geronimo. The use of global 
system properties is a real problem for us, not only because it 
precludes multiple instances in the same JVM but also because it makes 
the interface to JMX harder.

Several people have asked for alternative configuration mechanisms. 
However, this is a systemic issue for Derby and probably not easy to change.

--
Jeremy