"Knut Anders Hatlen (JIRA)" <[email protected]> writes: > [ > https://issues.apache.org/jira/browse/DERBY-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001117#comment-13001117 > ] > > Knut Anders Hatlen commented on DERBY-4963: > ------------------------------------------- > > Thanks for writing the release note, Rick. It is clear and looks > correct for the most part. The one thing I believe is inaccurate, is > the sentence "Solaris/JDK5 is one of these platforms." I don't think > Solaris is affected by this change, at least not on JDK 5. > > I think the only platforms affected are those that suffered from > DERBY-1, which are some old releases of Java 1.4.2 and Java 5 on Mac > OS/X and FreeBSD (and possibly other BSDs). And, looking at the code, > it probably also affects a code path taken by all JVMs at version > 1.4.0 and 1.4.1, but I'm not sure if we still support those variants > of 1.4 or if we require 1.4.2 now. > > Dag, does that sound correct, or did I garble things?
Sounds right. Quote from Derby-4741: Cf. DERBY-1 and check in LogToFile#openLogFileInWriteMode which calls checkJvmSyncError to determine this. The platforms mentioned are (e.g. early versions of 1.4.2 and 1.5 on Mac OS and FreeBSD As for Sun JVM 1.4.0 and 1.4.1, I have not investigated those, but what you say may be true. Thanks, Dag > >> Revert to FileDescriptor#sync from FileChannel#force to improve interrupt >> resilience >> ------------------------------------------------------------------------------------ >> >> Key: DERBY-4963 >> URL: https://issues.apache.org/jira/browse/DERBY-4963 >> Project: Derby >> Issue Type: Improvement >> Components: Store >> Reporter: Dag H. Wanvik >> Assignee: Dag H. Wanvik >> Fix For: 10.8.0.0 >> >> Attachments: derby-4963-1.diff, derby-4963-1.stat, >> derby-4963-2.diff, derby-4963-2.stat, releaseNote.html >> >> >> FileChannel.force is interruptable, and we really don't want to be >> interrupted when we flush the log file. Happily, on most platforms, we use >> the "rws"/"rwd" file open mask which makes the writes thjemselves >> synchronized, so no subsequent explicit file level sync is needed anyway. >> DirFile4#getRandowmAccessFile should use plain DirRandomAccessFile instead >> of the current DirRandomAccessFile4. This will make >> StorageRandomAccessFile#sync map to FileDescriptor#sync instead of >> FileChannel#force (also for NIO supporting platforms). >> Since FileDescriptor#sync does not allow synching file data only (it also >> synchronizes metadata), those platforms which do not support write >> synchronization will experience a performance drop, but this is the price we >> have to pay to survive interrupts without shutting down the database on >> those platforms. >> Users which experience this as a problem, should update to a newer JVM which >> does support "rws"/"rwd" in the mode argument to java.io.RandomAccessFile >> (http://download.oracle.com/javase/6/docs/api/java/io/RandomAccessFile.html#RandomAccessFile(java.io.File,%20java.lang.String). >> Cf. also discussion on >> https://issues.apache.org/jira/browse/DERBY-4741?focusedCommentId=12977862&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#action_12977862 >> .
