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.


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

View raw message