db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Knut Anders Hatlen <Knut.Hat...@Sun.COM>
Subject Re: Client/server plus network storage of database files
Date Tue, 23 Sep 2008 15:53:48 GMT
Daniel Noll <daniel@nuix.com> writes:

> Stanley Bradbury wrote:
>> The problem is that I/O across a network cannot to be guaranteed.
>> You are actually losing data buffered along the network when the
>> network fails.  Derby detects this when is boots the next time and
>> finds the checksums and timestamps on the files int the database are
>> out of sync.
>> Derby database files must reside local to the machine hosting the
>> Derby DBMS engine.
> So what does Derby define as "across a network"?  FireWire is
> technically a network protocol after all.

Derby doesn't define anything as "across the network", it just relies on
the file system to be well-behaved. So basically as long as the file
system guarantees that sync calls don't return until the changes have
been written to persistent storage, Derby should work OK. Otherwise, one
may end up with inconsistencies between the transaction log and the data
files, and the database is left in an unbootable state.

Another possible issue with Derby and network file systems, is that
Derby uses a file locking protocol to prevent double-booting of a
database. This protocol only works if the two instances that try to boot
Derby run on the same host. If they run on different hosts and access
the same database over a network fs, the database is likely going to be

Knut Anders

View raw message