db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Samuel Andrew McIntyre <fuzzylo...@nonintuitive.com>
Subject Re: release status as of 9/12/2004
Date Thu, 14 Oct 2004 06:49:33 GMT
Hash: SHA1

On Oct 12, 2004, at 3:16 PM, Dick Applebaum wrote:

> On Oct 12, 2004, at 2:29 PM, Samuel Andrew McIntyre wrote:
>> On Oct 12, 2004, at 1:12 PM, Dick Applebaum wrote:
>>> How about just doing a try/catch at start and turning the feature 
>>> off if you get an error?
>> I thought about that, but it wouldn't handle a case where rws mode 
>> doesn't throw any errors, but doesn't do what we need it to w/r/t 
>> flushing files to disk, which is why some people objected to changing 
>> from using rws mode to rwd mode. It would be safer to enable it only 
>> on JVMs whose rws mode has been certified through testing to work as 
>> expected.
> But how about specifying proven JVMs in an external file ala the 
> derby.properties -- so that a user could update  his system without a 
> complete reinstall, or more procedurally correct: by downloading the 
> latest provenJVM.properties file.

After thinking about this some more, I think the try/catch route may be 
the best way to go after all. I think it is in our best interest, as 
stated elsewhere, to remain as vendor-neutral as possible. I don't 
think that we want to get into the business of endorsing any particular 
vendor's JVMs. So, I don't think enabling or disabling a feature based 
on a list of vendors to include/exclude is really the best way to fix 
the problem, and doing so would set a bad precedent. slippery slope, 
and all that.

While the try/catch route may not seem like the cleaning solution to 
the problem, at least it could fix the issue where it is known to cause 
a problem without introducing unnecessary prejudice. So, if in the 
future the particular problem is fixed, the feature would be 
automatically enabled again, and we're still covered on any system 
where the JVM/OS combination still has the problem. And, in this 
particular case, if we encounter other difficulties with the different 
write sync modes elsewhere, we can (and should) treat them as separate 
problems that can have separate solutions.

Version: GnuPG v1.2.4 (Darwin)


View raw message