Return-Path: Delivered-To: apmail-db-derby-user-archive@www.apache.org Received: (qmail 17336 invoked from network); 13 May 2005 17:07:29 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 13 May 2005 17:07:29 -0000 Received: (qmail 64634 invoked by uid 500); 13 May 2005 17:11:40 -0000 Delivered-To: apmail-db-derby-user-archive@db.apache.org Received: (qmail 64325 invoked by uid 500); 13 May 2005 17:11:38 -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 64255 invoked by uid 99); 13 May 2005 17:11:37 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests= X-Spam-Check-By: apache.org Received-SPF: pass (hermes.apache.org: local policy) Received: from brmea-mail-3.Sun.COM (HELO brmea-mail-3.sun.com) (192.18.98.34) by apache.org (qpsmtpd/0.28) with ESMTP; Fri, 13 May 2005 10:11:37 -0700 Received: from phys-mpk-1 ([129.146.11.81]) by brmea-mail-3.sun.com (8.12.10/8.12.9) with ESMTP id j4DH7DjQ003543 for ; Fri, 13 May 2005 11:07:14 -0600 (MDT) Received: from conversion-daemon.mpk-mail1.sfbay.sun.com by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) id <0IGF00H01TT9U5@mpk-mail1.sfbay.sun.com> (original mail from David.Vancouvering@Sun.COM) for derby-user@db.apache.org; Fri, 13 May 2005 10:07:13 -0700 (PDT) Received: from sun.com (vpn-129-150-25-21.SFBay.Sun.COM [129.150.25.21]) by mpk-mail1.sfbay.sun.com (iPlanet Messaging Server 5.2 HotFix 1.24 (built Dec 19 2003)) with ESMTP id <0IGF004RIU76C5@mpk-mail1.sfbay.sun.com> for derby-user@db.apache.org; Fri, 13 May 2005 10:06:43 -0700 (PDT) Date: Fri, 13 May 2005 10:07:23 -0700 From: David Van Couvering Subject: Re: error when turning off auto commit In-reply-to: <4284DCA2.1080600@sbcglobal.net> To: Derby Discussion Message-id: <4284DECB.9060102@sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii; format=flowed Content-transfer-encoding: 7BIT X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 References: <42832271.8050707@visual-i.co.uk> <42838DA6.7090309@debrunners.com> <42848A05.1040105@visual-i.co.uk> <4284A58C.30109@debrunners.com> <4284DCA2.1080600@sbcglobal.net> X-Virus-Checked: Checked X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N I thought there was a bug where not closing statements accumulated memory, but it's just a rumor for me, not a direct experience. David Mike Matrigali wrote: > Does anyone know if it is expected in derby to accumulate memory in > a single transaction if you don't close statements or resultSets? > I am pretty sure not closing ResultSets is a problem, I am not sure > about Statements. > > Daniel John Debrunner wrote: > >> Chris wrote: >> >> >>> Hi, >>> >>> to demonstrate the problem, i've written some code which approximates >>> the code i'm using. (attached) >>> >>> I'm running Java 1.4.2 with the JVM parameter -Xmx64m. >>> >>> If you run the test() method, the memory used by the JVM rises to >>> above 150mb until the following exception happens: >> >> >> >> Thanks for the test case. >> >> I noticed that you are not using PreparedStatements for the query or the >> insert. Using PreparedStatements will make your program much faster, as >> the statement does not need to be recompiled every time. This is true >> for all JDBC drivers. >> >> See >> >> http://incubator.apache.org/derby/manuals/tuning/perf21.html#HDRSII-PERF-18705 >> >> >> E.g. >> >> PreparedStatement psq = conn.prepareStatement("SELECT id FROM test WHERE >> id = ?"); >> psq.setInt(1, id); >> ResultSet rs = psq.executeQuery(); >> >> >> Your code uses a new Statement object to execute every statement, which >> can also be avoided since Statement objects are reuseable. Though I >> would recommend PreparedStatements. >> >> Also your code never closes the Statement or ResultSet objects it >> creates, this may be contributing to the problem. >> >> Applying the above techniques may allow you to progress past this issue, >> though it should still be seen as a bug. >> >> Dan. >> >> >> >> >> >