Yes many things are possible technically - I did not mention the classloader
thing because 1) it's very likely not going to be the most common use case
(80-20 rule), 2) I think the original idea is to come up with a simple
solution to the issue of code sharing between the client and the derby
engine - if people want to come up with sophisticated frameworks to allow
loading of specific classpath/archives, then it is fine; but I don't think
we should make this the default case/solution - to me this belongs to the
real of application server framework, not the database one which is Derby's
main focus. This is something that can be done even today outside of Derby.
--francois
On 9/12/05, Jeremy Boynes <jboynes@apache.org> wrote:
>
> Francois Orsini wrote:
> <snip/>
>
> > Due to the requirement of supporting a different version of the derby
> client
> > and server in the same JVM, it's not like there are a lot of other and
> > simpler alternatives out there indeed...Am guessing we're not going to
> > support the loading of 2 different DerbyClient versions in the same
> > JVM...(although one could envision db2jcc.jar and DerbyClient.jarrunning in
> > the same JVM...we should not be seeing any conflict if the package
> structure
> > is different)
>
> I see no reason why we should not support that assuming the
> infrastructure allows them to be loaded into different classloaders. For
> example, each could be packaged inside a different RAR file and deployed
> to an application server. A use case for this is different applications
> talking to different databases.
>
> Similarly I think we should also allow multiple versions of the engine
> to be loaded as well (although not accessing the same data files).
> Support for this though requires evolution away from the reliance on
> system properties.
>
> The use case here is isolation between the engines - for example, if an
> application server is being used to host applications from different
> organizations.
>
> --
> Jeremy
>
|