Hi, please see comment inlined.
>>>>> "DVC" == David Van Couvering <[EMAIL PROTECTED]> wrote: DVC> DVC> Jeremy Boynes wrote: DVC> DVC> > I would like to explore the possibility of running multiple Derby DVC> > instances in the same JVM, probably in different classloaders. DVC> DVC> You use the term "Derby instance" but I'm not sure what you mean here. DVC> DVC> Based on a discussion I had with Dan, a Derby "system" is the union of DVC> all databases running under the same classloader. Is that what you DVC> mean? Each system is supposed to have its own configuration. But I had DVC> trouble figuring out how to do this with multiple classloaders (see your DVC> system properties discussion below), and nowhere do I see this tested DVC> currently. DVC> DVC> I thought Dag, with Kathey's help, was able to configure things such DVC> that you could have different Derby properties set for different DVC> databases in the same VM. Dag, how did that work again? Actually, no. What I did was for my test was to unload Derby (system) and then re-load it a number of times with different system property values set (see test lang/errorStream.java). Dag DVC> DVC> > DVC> > One use for that is an application server configuration where different DVC> > applications may require different versions of Derby or where different DVC> > instances may have different requirements e.g. for security. DVC> > DVC> > Two big issues come to mind: DVC> > 1) use of system properties DVC> > I would like to explore ways in which these can be replaced with a DVC> > per-instance configuration mechanism where each instance can have DVC> > separate properties. This could be as simple as a per-classloader DVC> > static property map but ideally something a little more flexible DVC> > would be useful DVC> DVC> Well, I would love us moving to JMX. It would solve a lot of problems DVC> around configuration for us, and it would also enable management by nice DVC> pretty GUIs, integration into larger systems managed by JMX (e.g. most DVC> app servers), etc. DVC> DVC> I recognize this a change with system-wide impact which can not be taken DVC> upon lightly. We'd also have to do it in a way that is pluggable, JMX DVC> is not something I expect is part of J2ME... DVC> DVC> X> DVC> > 2) common touch point in DriverManager, especially for use within DVC> > stored procedures. DVC> > I think we can do something here with a special Driver implementation DVC> > that could handle multiple engine instances which I think makes this DVC> > related to David Van Couvering's common jar discussion. DVC> DVC> I don't understand this point, could you explain further? DVC> DVC> That said, I do agree if what you are discussing involves multiple DVC> classloaders, then I think there is some crossover here and we should DVC> talk to make sure I don't design something that will require rework DVC> later on to support what you are envisioning here. DVC> DVC> David DVC> DVC> > DVC> > Thoughts? DVC> > -- DVC> > Jeremy DVC> -- Dag H. Wanvik Sun Microsystems, Web Services, Database Technology Group Haakon VII gt. 7b, N-7485 Trondheim, Norway Tel: x43496/+47 73842196, Fax: +47 73842101 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ NOTICE: This email message is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply email and destroy all copies of the original message. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
