Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
From: "Pasi Paasiala" <pasi.paasiala@solibri.com>
To: "'Derby Discussion'" <derby-user@db.apache.org>
References: <011d01caa4cf$3f60bb50$be2231f0$%paasiala@solibri.com>
 <4B6977F2.5010902@Sun.COM>
 <012d01caa4db$98557190$c90054b0$%paasiala@solibri.com>
 <4B6AC2AD.70907@Sun.COM>
In-Reply-To: <4B6AC2AD.70907@Sun.COM>
Subject: RE: how to get rid of the derby.rawStoreDaemon thread
Date: Thu, 4 Feb 2010 16:17:51 +0200
Message-ID: <001f01caa5a4$d6442450$82cc6cf0$@paasiala@solibri.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="US-ASCII"
Content-Transfer-Encoding: 7bit
Thread-Index: AcqlmOgJrVwVa/nEQIyNNfkvl86PBgAC+TaA
Content-Language: fi

Kristian,

Thank you very much again!

Pasi

-----Original Message-----
From: Kristian.Waagan@Sun.COM [mailto:Kristian.Waagan@Sun.COM] 
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: 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,
>