db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kathey Marsden <kmarsdende...@sbcglobal.net>
Subject Re: default holdability
Date Wed, 22 Feb 2006 22:46:10 GMT
Bernt M. Johnsen wrote:

I sent a response on this thread earlier but somehow it didn't make it
through, so am resending. My apologies if it shows up again later.

>Hi all,
>Allthough I agree that backwards compatability is important, I find
>the current default unfortunate 
Maybe unfortunate but the way  I think it has to stay.

*-1*   to changing the default holdability

We have to have a seamless upgrade that does not require application
changes.  It is essential to the sustainability of Derby.  I have said this many times before
but perhaps have not explained why, so  I'll go into some detail on this case.

Changing the holdability default  could potentially break thousands of
existing applications, each of which is deployed to thousands of
customers.  Often these applications exist as  components in other
products.  We have no support for dual load of Derby in the same JVM 
and so these applications are bound together in terms of what version of
Derby they share. The component that had planned no changes  suddenly
needs to scramble to change it to allow the other to upgrade, maybe just
to get a  bug fix.    Sometimes there are three or four components in
the picture each of which has tested on different versions of Derby.   
The dependencies and the ripple effect of a change like this are  immense.

The ultimate effect will be that the vendors supporting Derby will no
longer be able to roll up fixes but will find themselves cutting 
patches on old releases and supporting old releases for a very long time.
Ultimately the dependencies deteriorate to the point that there is
not good solution without a  joint  effort on the part of multiple
application vendors support teams, development teams and QA.

I think ultimately if we can support loading Derby in multiple class
loaders, we document how to do that, and we get our installed user base
doing it that way be default, we will have more flexibility.  For now we
don't have it.  Still I would vote -1 on this one.


View raw message