On 11/18/05, Mike Matrigali <[EMAIL PROTECTED]
> wrote:
Absolutely but I'm not sure how this would NO longer be posible - even with the new proposal, you could still run 4 different instances of Derby in the same JVM, assuming the database directories are different because of the lock file...and that you are using separate classloaders as most application servers would to run a particular deployed app.
There is a little difference between running 2 different instances of Derby engines in the same JVM _versus_ running a derby client at a different version level than a derby engine running in the same JVM - the latter presently works fairly well since we have no shared component to worry about between a client and some engine running in the same JVM. I'm not sure you're talking about the latter case - the potential issues of running several derby (engine) instances in the same JVM were (or should say are) already there without code sharing (i.e. required derby engine instances at a different version level had to run under under separate classloaders in the same JVM)...
You're right that we try and make the integration of Derby in embedded environments as painless as possible...
Due to the embedded nature of derby, and if it were to become popular I
believe that it may be common for users to wish to run multiple
instances of Derby in the same VM (actually I don't think users will
know anything about it as they will be running some other piece of
software that has chosen Derby so that they could seamlessly run
a database without letting the user know anything about it). I
know with Cloudscape there were cases of at least 4 instances of
Cloudscape in a given JVM, all layered within products that did
not anything about the other pieces of software.
Absolutely but I'm not sure how this would NO longer be posible - even with the new proposal, you could still run 4 different instances of Derby in the same JVM, assuming the database directories are different because of the lock file...and that you are using separate classloaders as most application servers would to run a particular deployed app.
Now we can pile hurdles in front of the users or the applications
embedding Derby and that will work for some number. But any hurdle
will mean less adoption of Derby.
I understand that the compatibility stuff is a pain, but if Derby
can solve it then it make it stand out. Just as the soft/hard
upgrade stuff is a pain to developers but will enable it's use in
some applications that otherwise could not adopt Derby.
There is a little difference between running 2 different instances of Derby engines in the same JVM _versus_ running a derby client at a different version level than a derby engine running in the same JVM - the latter presently works fairly well since we have no shared component to worry about between a client and some engine running in the same JVM. I'm not sure you're talking about the latter case - the potential issues of running several derby (engine) instances in the same JVM were (or should say are) already there without code sharing (i.e. required derby engine instances at a different version level had to run under under separate classloaders in the same JVM)...
You're right that we try and make the integration of Derby in embedded environments as painless as possible...
David Van Couvering wrote:
> Hi, all. I've been reading Kathey's email about her work on a
> classloader that can isolate Derby instances (and the trouble she's been
> having with system properties), and I'd like to pose something to the list.
>
> I am thinking (and I think Kathey's thinking along the same lines)
> perhaps there is a way to either transparently or with very little work
> from the user (e.g. a property on the connection URL) make it possible
> to isolate loading of Derby classes using some kind of specialized
> classloader.
>
> *If* I can figure something out, this could remove the requirement to
> support backward and forward compatibility, which is a serious albatross
> right now around shared code.
>
> Is this work that you think is valuable, or am I chasing a red herring
> (lots of bird analogies in this email).
>
> Thanks,
>
> David
>
>
>
