Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: neutral (hermes.apache.org: local policy)
Message-ID: <42B2433D.3010402@debrunners.com>
Date: Thu, 16 Jun 2005 20:27:57 -0700
From: Daniel John Debrunner <djd@debrunners.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.7.3) Gecko/20040910
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Is it possible to force read-only mode?
References: <42AF850F.4070908@nuix.com.au>
 <x1ofpsuohrhk.fsf@atum11.Norway.Sun.COM> <42B10A3C.6050605@nuix.com.au>
 <42B1B74D.6010505@sbcglobal.net> <42B22F41.1000805@nuix.com.au>
In-Reply-To: <42B22F41.1000805@nuix.com.au>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

Daniel Noll wrote:


> 
>    5. The two hosts might not even be on the same network segment, and
>       thus would be unable to intercommunicate at all.


If that's the case then even NFS won't work, right?

> 
> It seems like this problem wouldn't exist at all if Derby didn't try to
> lock the database.  My real question is, if I want to open it in
> read-only mode anyway, what business does it have locking it from other
> readers?

Because the readers wouldn't see a consistent, correct view of the
database, and may have unpredictable failures. Readers in this case are
a separate JVM running Derby opening the files in read only mode that
are in use by another JVM running Derby. This mode is not supported.

It is not supported because the active Derby engine does not write every
update to disk as soon as it happens. It uses a write-ahead logging
(WAL) system which ensures transaction durability without requiring all
data changes to be made to disk. This is a performance benefit, if a
transaction modifies, say, five rows then with a WAL scheme only one
disk i/o is required to commit the transaction. Without WAL there would
be up to five i/o's to commit.

The outcome of this is that the on-disk image of the data (as seen by
your reader) is not in a consistent state. Any page from a table may be
very stale because the modified fresh version is still in the cache of
the active Derby system, or it may contain uncommitted data because the
active system had to write a modified page out to free up some space,
but the transaction has not committed. Also maybe the on-disk data may
not be structually sound, say for a btree index. May contain pages that
point to pages that have not yet been written out. This inconsistent
state is brought to consistency by an active system when it boots by
running roll forward recovery, it reads the transaction log and redoes
committed changes and undoes uncommitted changes.

Active Runtime -> Correct state = (in-memory state + disk state)

Active booting -> Correct state = (disk state + transaction log + roll
forward recovery)

So at no point is just the on-disk state a useful snapshot of the database.

Dan.