On 03.02.10 15:17, Pasi Paasiala wrote:
Kristian,

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

Pasi,

If you want to manually invoke a checkpoint and freeze the database, you have to use some of Derby's system procedures:
http://db.apache.org/derby/docs/dev/ref/ref-single.html#crefsqlbuiltinsystemprocedures

Those of most interest in this case should be:
SYSCS_UTIL.SYSCS_CHECKPOINT_DATABASE
SYSCS_UTIL.SYSCS_FREEZE_DATABASE
SYSCS_UTIL.SYSCS_UNFREEZE_DATABASE

There is also some information in the administration guide (for instance http://db.apache.org/derby/docs/dev/adminguide/adminguide-single.html#cadminbckupdb ).


Regards,
--
Kristian

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: [email protected] [mailto:[email protected]]
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,

Reply via email to