Return-Path: 
 <derby-user-return-1257-apmail-db-derby-user-archive=db.apache.org@db.apache.org>
Delivered-To: apmail-db-derby-user-archive@www.apache.org
Received: (qmail 70161 invoked from network); 13 May 2005 01:48:59 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199)
  by minotaur.apache.org with SMTP; 13 May 2005 01:48:59 -0000
Received: (qmail 76530 invoked by uid 500); 13 May 2005 01:53:09 -0000
Delivered-To: apmail-db-derby-user-archive@db.apache.org
Received: (qmail 76511 invoked by uid 500); 13 May 2005 01:53:09 -0000
Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:derby-user-help@db.apache.org>
list-unsubscribe: <mailto:derby-user-unsubscribe@db.apache.org>
List-Post: <mailto:derby-user@db.apache.org>
List-Id: <derby-user.db.apache.org>
Reply-To: "Derby Discussion" <derby-user@db.apache.org>
Delivered-To: mailing list derby-user@db.apache.org
Received: (qmail 76495 invoked by uid 99); 13 May 2005 01:53:09 -0000
X-ASF-Spam-Status: No, hits=0.0 required=10.0
	tests=
X-Spam-Check-By: apache.org
Received-SPF: neutral (hermes.apache.org: 32.97.110.130 is neither permitted
 nor denied by domain of suresh.thalamati@gmail.com)
Received: from e32.co.us.ibm.com (HELO e32.co.us.ibm.com) (32.97.110.130)
  by apache.org (qpsmtpd/0.28) with ESMTP; Thu, 12 May 2005 18:53:08 -0700
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com
 [9.17.195.11])
	by e32.co.us.ibm.com (8.12.10/8.12.9) with ESMTP id j4D1mr0c310304
	for <derby-user@db.apache.org>; Thu, 12 May 2005 21:48:54 -0400
Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com
 [9.17.195.168])
	by westrelay02.boulder.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id
 j4D1mrck368790
	for <derby-user@db.apache.org>; Thu, 12 May 2005 19:48:53 -0600
Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1])
	by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id j4D1mr77013811
	for <derby-user@db.apache.org>; Thu, 12 May 2005 19:48:53 -0600
Received: from [127.0.0.1] (tsuresh-009030144218.svl.ibm.com [9.30.144.218])
	by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id j4D1mqY4013776
	for <derby-user@db.apache.org>; Thu, 12 May 2005 19:48:53 -0600
Message-ID: <42840780.2010402@gmail.com>
Date: Thu, 12 May 2005 18:48:48 -0700
From: Suresh Thalamati <suresh.thalamati@gmail.com>
User-Agent: Mozilla Thunderbird 1.0 (Windows/20041206)
X-Accept-Language: en-us, en
MIME-Version: 1.0
To: Derby Discussion <derby-user@db.apache.org>
Subject: Re: Database shutdown
References: <1115908157.4538.9.camel@spar.atlantic.ocean>
 <000b01c55707$2b24d970$38577553@DB35TT0J>
In-Reply-To: <000b01c55707$2b24d970$38577553@DB35TT0J>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
X-Virus-Checked: Checked
X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N

If  the database is being properly shutdown , one case I can think, 
which might make Derby system spend
more time in recovery code  is rollback of the incomplete transactions; 
this can happen if you are crashing with
lot of  uncommitted long transactions.  Just curious
-   how much time is it spending in Logtofile.recover() code ?
-  are there lot of log files of large size in  the <database name>/ 
log  directory  ?

shutdown with the database name also should work.  Option without the 
database name shuts down the whole
cloudscape system not just one database.  Shutdown in derby throws 
exception,  you  may want to check
the error codes to make sure the system is being properly shutdown.

ij> connect 'jdbc:derby:wombat;shutdown=true';
ERROR 08006: Database 'wombat' shutdown.
ij> connect 'jdbc:derby:;shutdown=true';
ERROR XJ015: Derby system shutdown.


Thanks
-suresht
 
Piet Blok wrote:

> Andrew,
>
> Incidentally yesterday, when reading the new pdf manuals, I found out 
> about database shutdown, so I tried to implement it. From a shutdown 
> hook I call the following method:
>
>    protected void shutdown() {
>        Properties shutdownProperties = new Properties();
>        shutdownProperties.put("shutdown", "true");
>        try {
>            driver.connect("jdbc:derby:", shutdownProperties);
>        } catch (SQLException e) {
>            if (e.getErrorCode() == 50000) {
>                System.out.println(e.getLocalizedMessage());
>            } else {
>                e.printStackTrace();
>            }
>        }
>
>    }
>
> This works (up to now) perfectly. I believe the mistake you make is 
> adding the database name to the connection URL. In the above code 
> "driver" refers to an EmbeddedDriver instance, created like this:
>
>    private EmbeddedDriver driver = new EmbeddedDriver();
>
>> From this driver I obtained connections using, ofcourse, a database 
>> name.
>
>
> Kind regards,
>
> Piet Blok
>
> ----- Original Message ----- From: "Andrew Shuttlewood" 
> <andrew.shuttlewood@futureroute.co.uk>
> To: <derby-user@db.apache.org>
> Sent: Thursday, May 12, 2005 4:29 PM
> Subject: Database shutdown
>
>
>> We have a shutdown hook registered to close down our derby databases,
>> but every so often, even when the shutdown hook triggers, we find that
>> it spends a lot of time in LogToFile.recover
>>
>> Our shutdown hook looks something like
>>
>>        Runtime.getRuntime().addShutdownHook(new Thread(new Runnable(){
>>            public void run() {
>>                try {
>>                    Log.log(Level.INFO, "Attempting shutdown of Embedded
>> Core Driver.");
>>                    DriverManager.getConnection("jdbc:derby:" +
>> Foo.this.databaseName + ";shutdown=true");
>>                } catch (SQLException e) {
>>                    System.out.println("Shutdown: " +
>> Foo.this.databaseName);
>>                    Log.log(Level.INFO, "Embedded Core Driver Shut
>> Down", e);
>>                }
>>            }
>>        }));
>>
>> This seems to do the right thing (sort of), but it doesn't always seem
>> to work. Am I missing something? Is a shutdown hook the absolutely wrong
>> place to do this? Am I perhaps making a obvious mistake?
>>
>> I can't really see the problem which is very frustrating!
>>
>> Also, in terms of memory usage, is it possible to reduce the amount of
>> memory used by all instances to some degree as we may wish to use a
>> number of instances at any one time. I was planning on potentially using
>> SoftReferences to manage a database pointer and then "shutting down" as
>> necessary, but I would quite like it if there was a way of setting a
>> global max number of pages or some such. Is this possible?
>>
>>
>
>
>