Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 26463 invoked from network); 12 Dec 2007 20:52:48 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 12 Dec 2007 20:52:48 -0000 Received: (qmail 75173 invoked by uid 500); 12 Dec 2007 20:52:36 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 75140 invoked by uid 500); 12 Dec 2007 20:52:36 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 75129 invoked by uid 99); 12 Dec 2007 20:52:36 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Dec 2007 12:52:36 -0800 X-ASF-Spam-Status: No, hits=-1.0 required=10.0 tests=RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: local policy) Received: from [192.18.6.24] (HELO gmp-eb-mail-2.sun.com) (192.18.6.24) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 12 Dec 2007 20:52:12 +0000 Received: from fe-emea-10.sun.com (gmp-eb-lb-2-fe3.eu.sun.com [192.18.6.12]) by gmp-eb-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id lBCKqCYH002194 for ; Wed, 12 Dec 2007 20:52:14 GMT Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) id <0JSY00G01F9E0Z00@fe-emea-10.sun.com> (original mail from Knut.Hatlen@Sun.COM) for derby-user@db.apache.org; Wed, 12 Dec 2007 20:52:12 +0000 (GMT) Received: from localhost ([193.71.105.147]) by fe-emea-10.sun.com (Sun Java System Messaging Server 6.2-8.04 (built Feb 28 2007)) with ESMTPSA id <0JSY00M40FAZKRG0@fe-emea-10.sun.com> for derby-user@db.apache.org; Wed, 12 Dec 2007 20:52:12 +0000 (GMT) Date: Wed, 12 Dec 2007 21:51:48 +0100 From: Knut Anders Hatlen Subject: Re: Forcing Data to Disk on JPA Commit In-reply-to: <475FFB41.8030504@amberpoint.com> Sender: Knut.Hatlen@Sun.COM To: Derby Discussion Message-id: Organization: Sun Microsystems MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT References: <475FFB41.8030504@amberpoint.com> User-Agent: Gnus/5.110007 (No Gnus v0.7) Emacs/22.1 (usg-unix-v) X-Virus-Checked: Checked by ClamAV on apache.org Bryan Pendleton writes: >> later. Obviously, the data is being cached, which is generally a >> good thing. However, when a power outage occurs, there's no time for >> the cache to be written to the database. Transactions that happened >> two weeks earlier were not written to the database > > When a Derby transaction is committed, although the data pages > may not be immediately written to disk, the log records for that > transaction are immediately written to disk, before the commit finishes. > > So if the power should fail, when Derby is later restarted, it will > perform recovery, read the committed transaction data from the log, > and re-do those transactions. This is true, but many systems have enabled the write cache on the hard drive. This means that although Derby and the OS think the data have been written to non-volatile storage, they may still reside in the volatile write cache on the disk and can be lost in a power outage. Olav mentioned in one of his presentations that he had run some experiments where he cut the power while the database was under heavy load. When the write cache on the disk was enabled, Derby failed to recover in 3 out of 10 runs, and recovered with lost transactions in 2 out of 10 runs (see http://home.online.no/~olmsan/publications/pres/apachecon07eu/DerbyApacheCon07eu.pdf). With the write cache disabled, the database was successfully recovered in 10 out of 10 runs. I think most desktop systems have the disk write cache enabled by default. -- Knut Anders