I tried the following steps to create a simple readonly DB on file
system it seems to work fine for me.
1) shutdown the DB with no pending transaction (this step is same for
jars also), to avoid rollbacks during recovery on a readonly system.
2) disable(deny) write permission for all the files/directories
under databases directory for the user id. that is starting the DB.
3) derby store seems to recognize that database is read only if is it
unable to create/modify files under database directory.
4) start each JVM that access the database with property
derby.storage.tempDirectory (D"derby.storage.tempDirectory=c:/temp/x2")
to specify different
temp directory for each instance , for the queries to create
temporary files in different directories.
My guess is , you are not disabling the write permissions correctly
for the database directory on the OS. Otherwise it would not be able to
boot in the in the write mode at all, because it needs to crearte lock
files, and log files ..etc to do anything.
Thanks
-suresht
Daniel Noll wrote:
Daniel John Debrunner 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?
Suppose your NFS server is available as 192.168.1.10 and
192.168.2.10. Hosts on 192.168.1.0/24 and 192.268.2.0/24 can't access
each other, but they can _certainly_ access the fileserver.
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.
If someone was going to write to it, it wouldn't be read-only, would
it? I did say from the beginning that I wanted to open it in
read-only mode.
I don't understand why this is such a big issue for a filesystem, when
it allegedly works fine when the database is in a JAR file. Where is
your inconsistent state in that case?
Daniel
