Return-Path: Delivered-To: apmail-db-derby-dev-archive@www.apache.org Received: (qmail 17021 invoked from network); 8 Sep 2005 15:40:34 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 8 Sep 2005 15:40:34 -0000 Received: (qmail 52932 invoked by uid 500); 8 Sep 2005 15:40:34 -0000 Delivered-To: apmail-db-derby-dev-archive@db.apache.org Received: (qmail 52686 invoked by uid 500); 8 Sep 2005 15:40:33 -0000 Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm Precedence: bulk list-help: list-unsubscribe: List-Post: List-Id: Reply-To: "Derby Development" Delivered-To: mailing list derby-dev@db.apache.org Received: (qmail 52673 invoked by uid 99); 8 Sep 2005 15:40:33 -0000 X-ASF-Spam-Status: No, hits=0.0 required=10.0 tests=SPF_FAIL X-Spam-Check-By: apache.org Received: from [192.87.106.226] (HELO ajax.apache.org) (192.87.106.226) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Sep 2005 08:40:32 -0700 Received: from ajax.apache.org (ajax.apache.org [127.0.0.1]) by ajax.apache.org (Postfix) with ESMTP id F28D8149 for ; Thu, 8 Sep 2005 17:40:30 +0200 (CEST) Message-ID: <1396781821.1126194030991.JavaMail.jira@ajax.apache.org> Date: Thu, 8 Sep 2005 17:40:30 +0200 (CEST) From: "Knut Anders Hatlen (JIRA)" To: derby-dev@db.apache.org Subject: [jira] Commented: (DERBY-557) Client driver gets OutOfMemoryError when re-executing statement without closing ResultSet In-Reply-To: <2115081767.1126193619223.JavaMail.jira@ajax.apache.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N [ http://issues.apache.org/jira/browse/DERBY-557?page=comments#action_12322938 ] Knut Anders Hatlen commented on DERBY-557: ------------------------------------------ Quoting myself from derby-user: > FYI, I had a look in the client driver code. It seems like only > markClosed() is called on the open ResultSets when a statement is > re-executed. The difference between close() and markClosed() is > basically that close() additionally checks whether it should > auto-commit, nulls out the cursor and meta data, and calls > > connection_.CommitAndRollbackListeners_.remove(this); > > Could this be our memory leak? Is there any situation where one > shouldn't call close() on the result sets when re-executing? After I sent this mail, I ran a test with some println-statements in the client driver. When the OutOfMemoryError was thrown the CommitAndRollbackListeners_ list had around 17000 elements when using Statement, and around 300000 elements when using PreparedStatement. > Client driver gets OutOfMemoryError when re-executing statement without closing ResultSet > ----------------------------------------------------------------------------------------- > > Key: DERBY-557 > URL: http://issues.apache.org/jira/browse/DERBY-557 > Project: Derby > Type: Bug > Components: Network Client > Versions: 10.1.1.0, 10.1.2.0, 10.2.0.0 > Reporter: Knut Anders Hatlen > Priority: Minor > Fix For: 10.1.2.0, 10.2.0.0 > > When re-executing a statement without closing the old ResultSet, some of the old ResultSet's resources are not released, and the network client will eventually get an OutOfMemoryError. > Example: > Connection c = DriverManager.getConnection("jdbc:derby://localhost/mydb"); > PreparedStatement ps = c.prepareStatement("select * from sys.systables"); > while (true) { > ResultSet rs = ps.executeQuery(); > } > This code will run for some time and then throw an OutOfMemoryError. Same thing happens with Statement instead of PreparedStatement. If rs.close() is added in the loop, the code works. Explicitly closing the ResultSet should not be necessary according to this quote from the JDBC 3.0 spec: > For Select statements, the statement is complete when the associated result set is closed. The result set is closed as soon as one of the following occurs: > - all of the rows have been retrieved > - the associated Statement object is re-executed > - another Statement object is executed on the same connection -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira