db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Pasi Paasiala" <pasi.paasi...@solibri.com>
Subject RE: how to get rid of the derby.rawStoreDaemon thread
Date Wed, 03 Feb 2010 14:17:18 GMT
Kristian,

Thank you very much for your answers. Can you still elaborate, how can I
perform checkpoint and freeze?

I also tried the DriverManager.getConnection("jdbc:derby:;shutdown=true");
and it seemed to work.
The only problem is that it always seems to throw an exception. Is that
something to be expected? If so, then I just catch it and don't worry about
it.

Pasi

-----Original Message-----
From: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM] 
Sent: 3. helmikuuta 2010 15:20
To: Derby Discussion
Subject: Re: how to get rid of the derby.rawStoreDaemon thread

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
>
>    


Mime
View raw message