db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Francois Orsini <francois.ors...@gmail.com>
Subject Re: VOTE: Approach for sharing code
Date Tue, 13 Sep 2005 05:32:43 GMT
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
>

Mime
View raw message