[ http://issues.apache.org/jira/browse/DERBY-210?page=comments#action_12363995 ]
Kathey Marsden commented on DERBY-210: -------------------------------------- I agree that garbage collection should not drive a commit, for the reasons stated by you and Dan and the fact that it is just to scary. It would mean non-holdable cursors will close, some transaction in progress can just commit out of the blue, etc, so it sounds like not a good thing to me. In terms of a repro, I would think you could repro the gc commit with your fix by 1) make sure autocommit is on 2) Execute a select with a holdable cursor and do not select the last row. 3) set the Statement reference to null. 4) Execute a select with a non-holdable cursor. Do not fetch the last row. 5) force gc. 6) Try to select the next row for the non-holdable cursor. It should say the cursor is closed because the gc would On whether a Statement.close() should drive a commit .. >From what was described earlier, the commit comes from the ResultSet >associated with the statement getting closed, not the statement itself. I am loathe to enter this conversation again, as the problem seems intractable so will offer only quotes for evaluation by the reader. >From section 10.1 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 The javadoc for Statement.close() >From Statement javadoc When a Statement object is closed, its current ResultSet object, if one exists, is also closed. The javadoc for ResultSet.close() A ResultSet object is automatically closed by the Statement object that generated it when that Statement object is closed, re-executed, or is used to retrieve the next result from a sequence of multiple results. A ResultSet object is also automatically closed when it is garbage collected. > Network Server will leak prepared statements if not explicitly closed by the > user until the connection is closed > ---------------------------------------------------------------------------------------------------------------- > > Key: DERBY-210 > URL: http://issues.apache.org/jira/browse/DERBY-210 > Project: Derby > Type: Bug > Components: Network Client > Reporter: Kathey Marsden > Assignee: Deepa Remesh > Attachments: derby-210.diff, derby-210.status, derbyStress.java > > Network server will not garbage collect prepared statements that are not > explicitly closed by the user. So a loop like this will leak. > ... > PreparedStatement ps; > for (int i = 0 ; i < numPs; i++) > { > ps = conn.prepareStatement(selTabSql); > rs =ps.executeQuery(); > while (rs.next()) > { > rs.getString(1); > } > rs.close(); > // I'm a sloppy java programmer > //ps.close(); > } > > To reproduce run the attached program > java derbyStress > Both client and server will grow until the connection is closed. > > It is likely that the fix for this will have to be in the client. The client > does not send protocol to close the prepared statement, but rather reuses the > PKGNAMCSN on the PRPSQLSTT request once the prepared statement has been > closed. This is how the server knows to close the old statement and create a > new one. -- 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
