-----BEGIN PGP SIGNED MESSAGE----- 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.
andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (Darwin)
iD8DBQFBbiGEDfB0XauCH7wRAmOvAJ9PbdNynBZF81IDGrUuC9LW3rykxwCbBekj qVZdgIk05GDoeUTOmFa+znE= =cPNA -----END PGP SIGNATURE-----
