Daniel Noll <[EMAIL PROTECTED]> 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 corrupted. -- Knut Anders
