Kristian, Thank you very much again!
Pasi -----Original Message----- From: [email protected] [mailto:[email protected]] Sent: 4. helmikuuta 2010 14:51 To: Derby Discussion Subject: Re: how to get rid of the derby.rawStoreDaemon thread 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#crefsqlbuiltinsystem procedures 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#cadmin bckupdb ). 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, >
