db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From dag.wan...@oracle.com (Dag H. Wanvik)
Subject Re: [jira] Commented: (DERBY-4963) Revert to FileDescriptor#sync from FileChannel#force to improve interrupt resilience
Date Wed, 02 Mar 2011 02:51:40 GMT
"Knut Anders Hatlen (JIRA)" <jira@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.


>> 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:
>>         Attachments: derby-4963-1.diff, derby-4963-1.stat, derby-4963-2.diff, derby-4963-2.stat,
>> 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

View raw message