From dev-return-6603-apmail-openjpa-dev-archive=openjpa.apache.org@openjpa.apache.org Tue Oct 30 14:37:15 2007 Return-Path: Delivered-To: apmail-openjpa-dev-archive@www.apache.org Received: (qmail 87857 invoked from network); 30 Oct 2007 14:37:15 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 30 Oct 2007 14:37:15 -0000 Received: (qmail 91890 invoked by uid 500); 30 Oct 2007 14:37:02 -0000 Delivered-To: apmail-openjpa-dev-archive@openjpa.apache.org Received: (qmail 91847 invoked by uid 500); 30 Oct 2007 14:37:02 -0000 Mailing-List: contact dev-help@openjpa.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@openjpa.apache.org Delivered-To: mailing list dev@openjpa.apache.org Received: (qmail 91838 invoked by uid 99); 30 Oct 2007 14:37:02 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2007 07:37:02 -0700 X-ASF-Spam-Status: No, hits=-100.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.4] (HELO brutus.apache.org) (140.211.11.4) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 30 Oct 2007 14:37:24 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id 5D5B07141FE for ; Tue, 30 Oct 2007 07:36:51 -0700 (PDT) Message-ID: <4055682.1193755011377.JavaMail.jira@brutus> Date: Tue, 30 Oct 2007 07:36:51 -0700 (PDT) From: "Albert Lee (JIRA)" To: dev@openjpa.apache.org Subject: [jira] Closed: (OPENJPA-415) Garbage collection of AbstractResultList instance closes active connection In-Reply-To: <250599.1193241530664.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/OPENJPA-415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Albert Lee closed OPENJPA-415. ------------------------------ > Garbage collection of AbstractResultList instance closes active connection > -------------------------------------------------------------------------- > > Key: OPENJPA-415 > URL: https://issues.apache.org/jira/browse/OPENJPA-415 > Project: OpenJPA > Issue Type: Bug > Components: jdbc > Affects Versions: 1.0.1, 1.1.0 > Reporter: Albert Lee > Assignee: Albert Lee > Fix For: 1.0.1, 1.1.0 > > Attachments: OPENJPA-415.patch > > > While investigation a problem, I noticed that garbage collection kicks in on the AbstractResultList's finalize() method. > ........ > at org.apache.openjpa.lib.jdbc.DelegatingConnection.close(DelegatingConnection.java:212) > at org.apache.openjpa.lib.jdbc.LoggingConnectionDecorator$LoggingConnection.close(LoggingConnectionDecorator.java:279) > at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$RefCountConnection.free(JDBCStoreManager.java:1288) > at org.apache.openjpa.jdbc.kernel.JDBCStoreManager$RefCountConnection.close(JDBCStoreManager.java:1273) > at org.apache.openjpa.jdbc.sql.ResultSetResult.close(ResultSetResult.java:182) > at org.apache.openjpa.jdbc.kernel.SelectResultObjectProvider.close(SelectResultObjectProvider.java:148) > at org.apache.openjpa.lib.rop.WindowResultList.free(WindowResultList.java:158) > at org.apache.openjpa.lib.rop.WindowResultList.close(WindowResultList.java:78) > at org.apache.openjpa.lib.rop.AbstractResultList.finalize(AbstractResultList.java:89) > at java.lang.J9VMInternals.runFinalize(J9VMInternals.java:406) > When traversing the call stack to the ResultSetResult.close() method, it is trying to close the result set unconditionally, and then close the associated statement and connection if they exists: > public void close() { > super.close(); > try { > _rs.close(); > } catch (SQLException se) { > } > if (_stmnt != null) > try { > _stmnt.close(); > } catch (SQLException se) { > } > if (_closeConn) > try { > _conn.close(); > } catch (SQLException se) { > } > } > Would this be a undesired side-effect and a problem in the following scenario: > 1) appl / openjpa obtains a connection > 2) create a prepare statement > 3) get a result set from the statement > 4) using the same statement and get another result set. The first result set is not being referenced by any code and ready for gc. > 5) the connection and statement is active for a long time and gc kicks in to gc the first result set instance > 6) eventually the ResultSetResult.close() gets call. > 7) The statement and connection gets closed while it is still being used by appl / openjpa. > Is this a possible scenario? > According to the JCA architecture, connection that is scoped to a transaction will be closed by the connection manager and all associated statements and result set managed by the connection will be automatically closed. So is the AbstractResultList.finalize() ever be needed at all? > Albert Lee. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.