I believe the problem is that derby just does not currently support
the type of read only that you want. It supports read only
connections, but not a database marked read only. It uses the lock
to coordinate with other connections which may try to access the
database.
I believe if one were to implement some sort of admin command which
marked a database as read only in the system catalogs somehow, and
made sure write connections figured it out and failed very early
in the boot process you could get what you are looking for. Things
to worry about:
1) When marking the database, you need to worry about outstanding
changes to data pages still in the cache and out standing log
records in the log before the most recent checkpoint. Otherwise
booting the database may require writes to data pages and or
log files and as soon as 2 JVMs are writing to data pages or log
files the db is almost sure to be corrupted.
2) Some read only queries still require temporary files, sort is the
most obvious example. Current Derby support of readonly db's still
allow these temp files, and assume that even if the derby db is
located on some truly read only media like a CD, that the application
will set a separate writable temp space. The names of the files
in the temp space are coordinated within a single JVM, but if 2 JVMs
accessed the same db on the same machine with the same temp space
it would not work as currently implemented.
Daniel Noll wrote:
Kathey Marsden wrote:
Daniel Noll wrote:
We have considered this option and discarded it for the time being.
Basically, our application isn't client-server, and probably won't be
for a while... probably a long while. We just wanted to implement a
cheap way for two people to look at the same database through our app
at the same time, possibly on different machines (the data would be
accessible via NFS, CIFS, or whatever.) Since no user needs to modify
the database (and doing so would be bad, for various reasons) I
figured that read-only mode could be used to do this.
I don't have real clarity on your configuration but I think the embedded
server model might be appropriate for what you are doing. Your app
continues to use embedded but you start network server in the same jvm
to allow access by external jvms.
You can probably test this very quickly to see if it is what you need by
setting the property derby.drda.startNetworkServer=true in your
derby.properties file and starting up your application. Then you can
safely connect with ij from another JVM.
My problem is something like this (I'll use the standard naming scheme
for arbitrary users)...
Suppose that Alice and Bob both want to open a database located at
file://server/data/case-001/Database .
You're saying that Alice's app can simply start an embedded server and
that Bob's app can connect to that server. The problems with this, as
we see it, are:
1. Bob's app has no way to figure out which host on its subnet is
running the server.
2. Even if the app knows which host is running the server, it has no
easy way to correlate the file it wants to open with a database
URL for remote connection.
3. If Alice decides to close her app, it will affect Bob's
connection, and we'll need sophisticated logic to make Bob's
app create a new embedded server, which Alice will then need
to connect to when she fails to connect to the database.
4. The situation becomes even more difficult if there are more
than one app running on the same host, which happens on
terminal server setups. Alice might open up one database and
Bob wants to open another, and both of these need to start
the embedded server in case Charlie wants to open either one.
Even if we ran each server on a different port somehow, which
port does charlie connect to?
5. The two hosts might not even be on the same network segment, and
thus would be unable to intercommunicate at all.
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?
Daniel
