db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David W. Van Couvering" <David.Vancouver...@Sun.COM>
Subject Re: Potentially removing compatibility requirements for shared code
Date Sat, 19 Nov 2005 00:26:33 GMT
Thanks, Mike.  I think we're in solid agreement here.  I think there is 
no debate that running multiple instances of Derby in the same VM 
without hurdles or impact to the user is the holy grail here.  Note, by 
the way, that the use of system properties is getting in the way even 
before shared code gets introduced.  Each instance of Derby needs to be 
isolatable within its own classloader, including all its configuration, 
and that currently doesn't exist.

What I am thinking of is a way to make it so code sharing allows this 
without requiring lots of compatibility hoops for the developer to jump 
through.  If this is not achievable, we'll continue with the 
hasFeature() mechanism that exists in the version I posted last week. 
But I am starting to hope (although it is still quite likely I am wrong) 
there may be a way around this.

I think what I should just do some prototyping and show it to you -- 
speak with code.  I was trying to test the waters before spending a lot 
of time on this, but I think my intent will become much more clear with 
some code.


Mike Matrigali wrote:
> 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.
> 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.
> 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

View raw message