Multiple systems in same VM -- does this really work?

[David Van Couvering <Da...@Sun.COM>]

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.

Thanks,

David

Re: Multiple systems in same VM -- does this really work?

[Daniel John Debrunner <dj...@debrunners.com>]

Jeremy Boynes wrote:


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

The general goal was to not rely on global properties, but to allow most
if not all properties to be set on a per-database level. This probably
hasn't been carried through completely, but it was a goal.

I think it's not clear from the documentation that properties like
derby.system.home are optional.

Dan.

Re: Multiple systems in same VM -- does this really work?

[David Van Couvering <Da...@Sun.COM>]

I think this might be a high-priority issue; I can see that a lot of 
uses of Derby will be within a container-based environment.  Multiple 
systems each with multiple databases could become a common configuration...

David

Jeremy Boynes wrote:

> 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

Re: Multiple systems in same VM -- does this really work?

[Jeremy Boynes <jb...@apache.org>]

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