db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Kristian Waagan <Kristian.Waa...@Sun.COM>
Subject Re: how to get rid of the derby.rawStoreDaemon thread
Date Wed, 03 Feb 2010 13:19:46 GMT
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 
  - 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:
(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:
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:

Note that the method you refer to above is not the recommended way to 
shut down the Derby engine.

Hope this helps,

> Regards,
> Pasi

View raw message