[
https://issues.apache.org/jira/browse/DERBY-3037?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12550131
]
Mamta A. Satoor commented on DERBY-3037:
----------------------------------------
Other than Activation.close(), there are 3 other places in the code, which call
Language Resultset.finish(). Those cases are listed below
1)impl.jdbc..EmbedResultSet.deleteRow() line 3789
Here we generate internal SQL to implement deleteRow. The internal sql is
DELETE FROM ..... WHERE CURRENT OF ........ After the execution of this sql, we
close the Language ResultSet, then finish the Language ResultSet and then we
close the Activation associated with that Language ResultSet. Theoretically, we
can simply reply on Activation.close to do the jobs of closing the Language
ResultSet, finishing the Language ResultSet and then closing itself. I will
give this a try once I address the failure in outerjoin.sql caused by my
earlier checkin for this jira entry.
2)impl.sql.execute.AlterTableConstantAction.executeUpdate() line 2242
The current code here looks like following
PreparedStatement ps = lcc.prepareInternalStatement(updateStmt);
// This is a substatement; for now, we do not set any timeout
// for it. We might change this behaviour later, by linking
// timeout to its parent statement's timeout settings.
ResultSet rs = ps.execute(lcc, true, 0L);
rs.close();
rs.finish();
As can be seen from code above, here too we execute an internal SQL statement
and after it's execution, we call close the Language ResultSet, then finish the
Language ResultSet. We do not currently get the handle to Activation object in
the code above. I can try to do following to avoid direct call to Language
Resultset.finish
PreparedStatement ps = lcc.prepareInternalStatement(updateStmt);
Activation act = ps.getActivation(lcc, false);
// This is a substatement; for now, we do not set any timeout
// for it. We might change this behaviour later, by linking
// timeout to its parent statement's timeout settings.
ResultSet rs = ps.execute(lcc, true, 0L);
act.close()
3)And lastly, impl.jdbc.EmbedStatement.executeStatement line 1276
Here, for sql statements that do not return rows, we call Language
Resultset.finish because we do not need the Language Resultset anymore(as per
the code in the comments). In this particular case, I do not think I can
simply call activation.close to finish the Language Resultset because
activation is still getting used after the Language Resultset has been
finished. I would like to know if I am interpreting this incorrectly.
Would appreciate feedback on these 3 items, especially item 3. I will start
working on 1 and 2 after I resolve the problem with outerjoin.sql
> Language ResultSet.finish() is called even when the ResultSet is going to be
> re-used.
> -------------------------------------------------------------------------------------
>
> Key: DERBY-3037
> URL: https://issues.apache.org/jira/browse/DERBY-3037
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.4.0.0
> Reporter: Daniel John Debrunner
> Assignee: Mamta A. Satoor
> Fix For: 10.3.2.2, 10.4.0.0
>
>
> DERBY-827 (correctly) changed the lifetime of the language ResultSet tree to
> be the lifetime of the activation, but did not fix up the correct calls to
> ResultSet.close() and ResultSet.finish().
> A language ResultSet's lifetime should be driven by the activation, so
> activation.close() should call finish() on its ResultSet.
> EmbedResultSet should call close on its language ResultSet (theResults field)
> when the JDBC ResultSet is closed, it should not be calling finish() on its
> ResultSet.
> See comments in DERBY-827 for some more details and issues.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
