On 03.02.10 13:48, Pasi Paasiala wrote:
We are evaluating derby to use it for storing additional information related
to our models (Java objects).
When we save our model, we save the database files and folders with it. The
only way that we have found to ensure that the database files are in a
consistent state is to close the connection before getting a snapshot of the
files and then start the database again. Is there another way of finding out
if all data is stored in the files?
Hi Pasi,
The results from committed transactions are always stored "in the
files": in the data files (in Derby's case in the 'seg0' directory)
*and* in the transaction log files (in the 'log' directory).
However, it is not safe to copy these files using file system utilities
(like copy or cp) while transactions are active. Some of the choices you
have:
- use the Derby online backup routines
- perform a checkpoint, freeze the database, copy using file system
utilities, then unfreeze the database
- properly shut down the database and copy using file system utilities
while the database isn't booted
To properly shut down a database, which includes performing a checkpoint
(amongst other things, this copies information from the transaction log
files to the data files), connect to the database with the following URL:
'jdbc:derby:myDB;shutdown=true'
(depending on the configuration you may have to provide other
attributes, like a user name and a password)
If you don't shut down the database properly, Derby has to do a recovery
the next time the database is booted (it starts with the data stored in
the data files and then applies the actions found in the log files).
Also note that shutting down a specific database and the Derby database
engine are two separate things. You shouldn't have to shut down the
engine to be able to obtain a consistent snapshot of your database.
You can find more information about these things in the manuals.
Another problem is that when we save a model and open another one, we close
the database and open another one. In that case we get another instance of
derby.rawStoreDaemon thread. Why doesn't the first derby.rawStoreDaemon shut
down even though we call Connection.close()? The only way that we have found
to shut down the thread is by calling:
Monitor.getMonitor().shutdown();
Even though you close the connection, the database engine is still
running. To shut down the database engine, you have to issue the
following command:
DriverManager.getConnection("jdbc:derby:;shutdown=true");
Note that in this case no database name is specified, and you shut down
the Derby engine.
I can't remember if there are supposed to be several rawStoreDaemon
threads (I think not, does anyone know for sure?), but do you still see
this if you shut down the engine properly?
However, if we call that, we get the following exception the next time we
try to make a connection:
java.sql.SQLException: org.apache.derby.jdbc.EmbeddedDriver is not
registered with the JDBC driver manager
at org.apache.derby.jdbc.AutoloadedDriver.getDriverModule(Unknown
Source)
at org.apache.derby.jdbc.AutoloadedDriver.connect(Unknown Source)
at java.sql.DriverManager.getConnection(DriverManager.java:582)
at java.sql.DriverManager.getConnection(DriverManager.java:207)
Someone else had had a similar kind of problem:
http://osdir.com/ml/derby-user-db-apache/2009-05/msg00027.html
This happens because you shut down the database engine. To force a new
instance to be loaded, you could do something like this:
Class.forName("org.apache.derby.jdbc.EmbeddedDriver").newInstance();
Note that the method you refer to above is not the recommended way to
shut down the Derby engine.
Hope this helps,
--
Kristian
Regards,
Pasi
