Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 92119 invoked from network); 29 May 2008 16:35:24 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 29 May 2008 16:35:24 -0000 Received: (qmail 95110 invoked by uid 500); 29 May 2008 16:35:25 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 95078 invoked by uid 500); 29 May 2008 16:35:25 -0000 Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Discussion" Delivered-To: mailing list derby-user@db.apache.org Received: (qmail 95067 invoked by uid 99); 29 May 2008 16:35:25 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 May 2008 09:35:25 -0700 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of Clint.Gilbert@childrens.harvard.edu designates 134.174.20.64 as permitted sender) Received: from [134.174.20.64] (HELO mail2.childrenshospital.org) (134.174.20.64) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 29 May 2008 16:34:31 +0000 Received: from tumsmtp2.CHBOSTON.ORG (tumsmtp2.tch.harvard.edu [10.20.50.56]) by mail2.childrenshospital.org (Postfix) with ESMTP id C4E788082 for ; Thu, 29 May 2008 12:34:52 -0400 (EDT) Received: from [10.20.50.4] by tumsmtp1.CHBOSTON.ORG with ESMTP (MMS SMTP Relay (Email Firewall v6.3.1)); Thu, 29 May 2008 12:34:46 -0400 X-Server-Uuid: 364F090E-629E-4BC8-811E-6F9312898D71 Received: from chexv2.chboston.org ([10.36.132.133]) by chexsmtp1.CHBOSTON.ORG with Microsoft SMTPSVC(6.0.3790.3959); Thu, 29 May 2008 12:34:46 -0400 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Subject: RE: Derby in Tomcat webapps Date: Thu, 29 May 2008 12:34:45 -0400 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Derby in Tomcat webapps Thread-Index: AcjBpsCXs1sLYLODRXO8oqytXdMcPQAALTDj References: <5627810d0805290855o59d140e9uddd1f0355f11b24b@mail.gmail.com> From: "Gilbert, Clint" To: "Derby Discussion" , "Derby Discussion" X-OriginalArrivalTime: 29 May 2008 16:34:46.0248 (UTC) FILETIME=[E7CA2E80:01C8C1A9] X-TMWD-Spam-Summary: TS=20080529163447; SEV=2.2.2; DFV=B2008052911; IFV=2.0.4,4.0-9; AIF=B2008052911; RPD=5.02.0125; ENG=IBF; RPDID=7374723D303030312E30413039303230422E34383345444232362E303238422C73733D312C6667733D30; CAT=NONE; CON=NONE X-MMS-Spam-Filter-ID: B2008052911_5.02.0125_4.0-9 X-WSS-ID: 642004AC0CK6968157-01-01 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org For what it's worth, I had a problem similar to the original poster's. = Upon restarting Tomcat, my embedded Derby DB would occasionally boot = read-only, or not at all - a problem on a development server that was = bounced frequently. This was using Hibernate and its built-in = connection pooling. It seemed that the DB was never getting properly = shut down. =20 I solved the problem by running the Derby network server on my local = machine and making connections to that instead of the embedded DB. = That's a lot less slick, however, so I plan to try using a "real" JNDI = datasource in the future. -----Original Message----- From: Robert J. Carr [mailto:rjcarr@gmail.com] Sent: Thu 5/29/2008 12:11 PM To: Derby Discussion Subject: Re: Derby in Tomcat webapps =20 > 1. When I unload and then reload the app, the new instance of the app = can't > start the database. I have to stop and then start Tomcat. My application runs in tomcat and I can deploy and undeploy my app and the database is fine and I'm able to reconnect. Are you unloading the database when you undeploy? > 2. When I try to run a second app that uses Tomcat, it can't start the > database. If you are using embedded derby, as far as I know, you can only have one active connection to it at a time. You might be able to get around this using JNDI data sources, which I think ties the connection to tomcat and not to your application. I haven't confirmed this, but it is worth a shot if you're not already doing it (and a better practice as well). Good luck!