Potentially removing compatibility requirements for shared code

[David Van Couvering <Da...@Sun.COM>]

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

Re: Potentially removing compatibility requirements for shared code

[David Van Couvering <Da...@Sun.COM>]

I'm a little confused, I thought that the requirement was to be able to
run two Derby apps at different version levels in the same VM (one using
the 10.2 network client driver and the other usin the 10.3 embedded driver).

If this was what you mean by "mixing of jars," then, yes, it was my
intention to allow this, but that we would make it possible to do this
without requiring compatibility rules upon shared code and without
impact on the users.  We already agreed that removing support for mixed
versions was not acceptable.

I think this is what you mean by "Horray!  go for it.", right?

Kathey Marsden wrote On 11/18/05 13:01,:
> David Van Couvering wrote:
> 
> 
>>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.
>>
>> 
>>
> 
> Some how I think the title of this mail  should be either:
> "I  think I can find a way to allow mixing of jars of different
> versions  in the same JVM without impact or changes required for
> existing applications!"
> In which case I say "Hooray! go for it."
> 
> or
> 
> "Remove  mixed jar capability all together  because we might be able to
> provide a workaround for users"
> In which case I say  "Not now! The current regressions planned are scary
> enough!"  Even if the applications can implement the workaround and
> release their products today, there is the installed user base to worry
> about, they can have an incidental  impact which shouldn't be exacerbated.
> 
> "Potentially removing compatibility requirements for shared code"   is 
> kind of like calling it "Potentially removing the requirement to balance
> your check book".  Sounds neat but  is there impact?
> 
> Kathey
> 
> 

Re: Potentially removing compatibility requirements for shared code

[Kathey Marsden <km...@sbcglobal.net>]

David Van Couvering wrote:

>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.
>
>  
>
Some how I think the title of this mail  should be either:
"I  think I can find a way to allow mixing of jars of different
versions  in the same JVM without impact or changes required for
existing applications!"
In which case I say "Hooray! go for it."

or

"Remove  mixed jar capability all together  because we might be able to
provide a workaround for users"
In which case I say  "Not now! The current regressions planned are scary
enough!"  Even if the applications can implement the workaround and
release their products today, there is the installed user base to worry
about, they can have an incidental  impact which shouldn't be exacerbated.

"Potentially removing compatibility requirements for shared code"   is 
kind of like calling it "Potentially removing the requirement to balance
your check book".  Sounds neat but  is there impact?

Kathey

Re: Potentially removing compatibility requirements for shared code

[Francois Orsini <fr...@gmail.com>]

On 11/18/05, Mike Matrigali <mi...@sbcglobal.net> 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.


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
> >
> >
> >
>
>

Re: Potentially removing compatibility requirements for shared code

["David W. Van Couvering" <Da...@Sun.COM>]

I think you can take your time.  I have plenty to work on with the 
feedback I already have.

And yes, the idea is to make things better without breaking anything.

Thanks,

David

Kathey Marsden wrote:
> David W. Van Couvering wrote:
> 
> 
>>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.
>>
> 
> Anything you can do that makes things better without breaking anything
> that exists is typically really easy sailing.  I am still finishing up
> my review of the hasFeature() stuff but trying to get the release out
> too. Can I take "end of the week" as "before Monday" in my usual liberal
> interpretation of deadlines?
> 
> 
> 
> 
> 

Re: Potentially removing compatibility requirements for shared code

[Kathey Marsden <km...@sbcglobal.net>]

David W. Van Couvering wrote:

> 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.
>
Anything you can do that makes things better without breaking anything
that exists is typically really easy sailing.  I am still finishing up
my review of the hasFeature() stuff but trying to get the release out
too. Can I take "end of the week" as "before Monday" in my usual liberal
interpretation of deadlines?

Re: Potentially removing compatibility requirements for shared code

["David W. Van Couvering" <Da...@Sun.COM>]

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.

David

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
>>
>>
>>
> 

Re: Potentially removing compatibility requirements for shared code

[Mike Matrigali <mi...@sbcglobal.net>]

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
> 
> 
>