The only exception to this rule is in the case of readonly databases.
Databases opened in readonly mode can be safely accessed by multiple
Why is all this Necessary?
InstantDB holds a lot of data in memory. Some of this only gets
written to disk as part of a clean shutdown. This is necessary
for performance reasons. (Note however that actual table data
always gets written to disk at the end of a transaction. Only
caches and indexing information are held in memory.)
If JVM 1 opens a database and then JVM 2 opens the same one,
JVM 2 will see that there is data missing. It will assume that
the database has not been cleanly shut down and will try to repair
the database. When JVM 1 shuts down it will corrupt the database
without realising it. This is illustrated in the diagram below.
This means for example that you cannot access the database from
a separate monitoring program while your main application has
the database open.
Using the RmiJdbc driver means that only the RMI server's JVM
actually has the database open. All of the client applications:
your main application(s) and any monitoring programs, access the
database indirectly via the RMI server.
a Clean Shutdown
InstantDB will close a database automatically when there are
no surviving database connections. You should always try to close
all connections before the JVM which has access to the database
Sometimes however this is not possible, particularly when the
database is being accessed via the RmiJdbc driver. In order to
force the database to shut down you can issue the SQL command:
This will do a clean shutdown by locking all the tables in the
database (thus ensuring that all existing transactions complete)
and then closing the database files.
If it is not possible to perform a shutdown, say because a particular
transaction is deadlocked, then the
option can be used. This forces all database files to close without
first locking the underlying tables.
If InstantDB opens a database and finds that data is missing
it cannot tell whether this is simply due to another JVM using
the database or whether it has failed to shut down cleanly and
needs to be recovered. By default InstantDB asks whether it should
perform recovery or not.
InstantDB's behaviour can be altered using the database property:
recoveryPolicy. Setting this value to 1 (one) causes InstantDB
to perform automatic recovery when it finds a corrupt database.
This is a useful policy when the database is being used as a server
and automated failover recovery is required.
Setting recoveryPolicy to 2 (two) makes InstantDB issue a prompt
on standard in whenever it encounters a potentially corrupt database.
This is useful during development when interactive monitoring
of the database is useful but might accidentally lead to corruption.
Setting recoveryPolicy to 0 (zero) makes InstantDB refuse to
open the database if data appears to be missing.