From derby-dev-return-85783-apmail-db-derby-dev-archive=db.apache.org@db.apache.org Wed Mar 02 02:52:33 2011 Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 22292 invoked from network); 2 Mar 2011 02:52:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 2 Mar 2011 02:52:33 -0000 Received: (qmail 26613 invoked by uid 500); 2 Mar 2011 02:52:33 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 26438 invoked by uid 500); 2 Mar 2011 02:52:31 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 26431 invoked by uid 99); 2 Mar 2011 02:52:31 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Mar 2011 02:52:31 +0000 X-ASF-Spam-Status: No, hits=-2.3 required=5.0 tests=RCVD_IN_DNSWL_MED,SPF_PASS,UNPARSEABLE_RELAY X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [148.87.113.121] (HELO rcsinet10.oracle.com) (148.87.113.121) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 02 Mar 2011 02:52:25 +0000 Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet10.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id p222q2wE001948 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Wed, 2 Mar 2011 02:52:04 GMT Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id p221Re0t010254 for ; Wed, 2 Mar 2011 02:52:02 GMT Received: from abhmt021.oracle.com by acsmt354.oracle.com with ESMTP id 1099843421299034304; Tue, 01 Mar 2011 18:51:44 -0800 Received: from localhost (/123.100.135.38) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 01 Mar 2011 18:51:44 -0800 From: dag.wanvik@oracle.com (Dag H. Wanvik) To: Subject: Re: [jira] Commented: (DERBY-4963) Revert to FileDescriptor#sync from FileChannel#force to improve interrupt resilience References: <1260709609.6085.1299014223842.JavaMail.tomcat@hel.zones.apache.org> Date: Wed, 02 Mar 2011 12:51:40 +1000 In-Reply-To: <1260709609.6085.1299014223842.JavaMail.tomcat@hel.zones.apache.org> (Knut Anders Hatlen's message of "Tue, 1 Mar 2011 21:17:03 +0000 (UTC)") Message-ID: User-Agent: Gnus/5.110011 (No Gnus v0.11) Emacs/23.1 (usg-unix-v) MIME-Version: 1.0 Content-Type: text/plain X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4D6DB0D2.00DC,ss=1,fgs=0 "Knut Anders Hatlen (JIRA)" 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 .