db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4963) Revert to FileDescriptor#sync from FileChannel#force to improve interrupt resilience
Date Wed, 02 Mar 2011 09:03:36 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4963?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13001345#comment-13001345
] 

Knut Anders Hatlen commented on DERBY-4963:
-------------------------------------------

My comment about 1.4.0 and 1.4.1 was based on this comment in LogToFile:

	 * Note: Why logging system support file sync and write sync ?
	 * Note : The reason to support file and write sync of logs is 
	 * there was no support to do write sync until jdk1.4 and then
	 * there was write sync jvm bug in jdk1.4.1, only in jdk1.4.2 write 
	 * sync(rws and rwd modes) mechanism can be used correctly.
	 * Default in JVMS >= jdk1.4.2 is write sync(see the boot method for jvm checks).

And in DirStorageFactory4:

	private static final boolean	rwsOK = JVMInfo.JDK_ID >= JVMInfo.J2SE_142;

> 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

        

Mime
View raw message