Return-Path: Delivered-To: apmail-tomcat-users-archive@www.apache.org Received: (qmail 40396 invoked from network); 25 Jan 2008 21:46:07 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 25 Jan 2008 21:46:07 -0000 Received: (qmail 86610 invoked by uid 500); 25 Jan 2008 21:45:44 -0000 Delivered-To: apmail-tomcat-users-archive@tomcat.apache.org Received: (qmail 86583 invoked by uid 500); 25 Jan 2008 21:45:44 -0000 Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: "Tomcat Users List" Delivered-To: mailing list users@tomcat.apache.org Received: (qmail 86572 invoked by uid 99); 25 Jan 2008 21:45:44 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Jan 2008 13:45:44 -0800 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: local policy) Received: from [64.106.242.101] (HELO mail.summerhost.net) (64.106.242.101) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 25 Jan 2008 21:45:30 +0000 Received: from ss.summerhost.net (ss.summerhost.net [64.106.242.102]) by mail.summerhost.net (Postfix) with ESMTP id 0C8A4F4B80 for ; Fri, 25 Jan 2008 16:40:02 -0500 (EST) Received: from ss.summerhost.net (ss.summerhost.net [64.106.242.102]) by ss.summerhost.net (Postfix) with ESMTP id BBD223C890 for ; Fri, 25 Jan 2008 16:40:02 -0500 (EST) Received: from 69.22.229.55 (SquirrelMail authenticated user tc) by ss.summerhost.net with HTTP; Fri, 25 Jan 2008 16:40:02 -0500 (EST) Message-ID: <1631.69.22.229.55.1201297202.squirrel@ss.summerhost.net> In-Reply-To: <4794B7EE.9010302@christopherschultz.net> References: <1974.69.22.229.55.1200848596.squirrel@ss.summerhost.net> <4794B7EE.9010302@christopherschultz.net> Date: Fri, 25 Jan 2008 16:40:02 -0500 (EST) Subject: Re: Tomcat App becomes Unresponsive From: "tc" To: users@tomcat.apache.org Reply-To: tc@summerhost.net User-Agent: SquirrelMail/1.4.9a MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Checked: Checked by ClamAV on apache.org > -----BEGIN PGP SIGNED MESSAGE----- > > Are you using a connection pool? If so, which one? > I'm trying to figure this out. I don't see any evidence of one configured in the server.xml file. If not, I presume it would be a good idea for us to start using one? > You need to make sure that you call "close" on /everything/ when you're > done with your Connection, Statement (and subclass), and ResultSet (and > subclass) objects. Check to make sure that those close calls are done in > "finally" blocks, and that a failure to close a ResultSet does not cause > an exception to be thrown that avoids the Connection close. > > For example: > > Connection conn = getConnection(); > > PreparedStatement ps = conn.prepareStatement("SELECT 1"); > > ResultSet rs = ps.executeQuery(); > > ... > > rs.close(); > ps.close(); > conn.close(); > > return null; > > This is not good. What you really need is this: > > Connection conn = null; > PreparedStatement ps = null; > ResultSet rs = null; > > try > { > ~ conn = getConnection(); > ~ ps = ...; > ~ rs = ...; > > ~ ... > } > finally > { > ~ if(null != rs) > ~ try { rs.close(); } catch (SQLException sqle) { /* log */ } > ~ if(null != ps) > ~ try { ps.close(); } catch (SQLException sqle) { /* log */ } > ~ if(null != conn) > ~ try { conn.close(); } catch (SQLException sqle) { /* log */ } > } > > Note how all the cleanup is done in the finally block (so the cleanup > code will run even during an exception situation), and that each "close" > is called in its own try/catch block: this prevents the failure to close > the (e.g.) ResultSet from preventing the Statement or Connection from > closing. Remember to log anything weird. > The calls look like this: public void testXXX(DataSource ds, String login) { PreparedStatement ps=null; ResultSet rs=null; try { conn = ds.getconnection(); ps = conn.prepareStatement("SELECT * from test"); ps.setString(1,login); rs = ps.executeQuery(); if(rs.next()){ //do something with the data } }catch (Exception e) { System.out.println("Exception: " + e); e.printStackTrace(); } finally { try { try { if(rs != null) rs.close();rs=null; } catch (Exception e) { e.printStackTrace(); } try { if (ps != null) ps.close();ps=null; } catch (Exception e) { e.printStackTrace(); } try { if(conn != null || conn.isClosed()) conn.close(); } catch (Exception e) { e.printStackTrace(); } } catch (Exception e) { e.printStackTrace(); } } } I see that we are not using specifically catching "SQLException sqle" - should we be? Further info on our system (sorry for the earlier omission): We are running Red Hat Enterprise Linux 4.0 Tomcat 5.5 Java 1.5.0_11 I also found two different mysql connector files. I'm not sure which one (if either) is being used: mysql-connector-java-3.1.14-bin.jar mysql-connector-java-5.0.0-beta-bin.jar --------------------------------------------------------------------- To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org For additional commands, e-mail: users-help@tomcat.apache.org