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.
