You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by "Knut Anders Hatlen (JIRA)" <ji...@apache.org> on 2011/03/01 22:17:03 UTC
[jira] Commented: (DERBY-4963) Revert to FileDescriptor#sync from
FileChannel#force to improve interrupt resilience
[ 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?
> 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 .
--
This message is automatically generated by JIRA.
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [jira] Commented: (DERBY-4963) Revert to FileDescriptor#sync from FileChannel#force to improve interrupt resilience
Posted by "Dag H. Wanvik" <da...@oracle.com>.
"Knut Anders Hatlen (JIRA)" <ji...@apache.org> 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 .