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 Thu, 04 Feb 2010 12:50:53 GMT
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?


If you want to manually invoke a checkpoint and freeze the database, you 
have to use some of Derby's system procedures:

Those of most interest in this case should be:

There is also some information in the administration guide (for instance 


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

View raw message