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