[
https://issues.apache.org/jira/browse/DERBY-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739086#action_12739086
]
Rick Hillegas commented on DERBY-4330:
--------------------------------------
Thanks for the patch, Dag. Here's my understanding of the general problem you
have found: When a ResultSet encounters an error at open() time, it fails to
close its ResultSet children. I wonder if there is another version of this bug
hanging around in the ResultSet.close() methods themselves: If an error occurs
during the close of one child of a ResultSet, will the other children be closed
or will they dangle open? It may be that you will bag more instances of this
bug if you do the following:
1) Make the ResultSet.close() methods more defensive so that they continue
closing the rest of their children even if one child raises an error during
close().
2) Have the ResultSet call its own close() method if an error occurs during
open().
Thanks,
-Rick
> NullPointerException or assert failure when re-executing PreparedStatement
> after lock timeout
> ---------------------------------------------------------------------------------------------
>
> Key: DERBY-4330
> URL: https://issues.apache.org/jira/browse/DERBY-4330
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.3.1.4, 10.3.2.1, 10.3.3.0, 10.4.1.3, 10.4.2.0,
> 10.5.1.1, 10.5.2.0, 10.6.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Dag H. Wanvik
> Attachments: derby-4330a.diff, derby-4330b.diff, derby-4330b.stat,
> repro-intersect.sql, repro-union.sql, repro.sql
>
>
> I came across a query that failed with a NullPointerException (insane jars)
> or an assert failure (sane jars) when a PreparedStatement was re-executed
> after a lock timeout. I'm able to reproduce this on 10.3.1.4 and later.
> 10.2.2.0 and earlier don't fail. Another fallout from DERBY-827? I've also
> seen other manifestations of the problem, apparently depending on the actual
> rows in the tables, including "No current connection" and "The heap container
> with container id Container(0, 1120) is closed".
> Stack trace for the assert failure:
> org.apache.derby.shared.common.sanity.AssertFailure: ASSERT FAILED
> JoinResultSet already open
> at
> org.apache.derby.shared.common.sanity.SanityManager.ASSERT(SanityManager.java:120)
> at
> org.apache.derby.impl.sql.execute.JoinResultSet.openCore(JoinResultSet.java:144)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:169)
> at
> org.apache.derby.impl.sql.execute.SortResultSet.openCore(SortResultSet.java:248)
> at
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.openCore(ProjectRestrictResultSet.java:169)
> at
> org.apache.derby.impl.sql.execute.BasicNoPutResultSetImpl.open(BasicNoPutResultSetImpl.java:248)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(GenericPreparedStatement.java:416)
> at
> org.apache.derby.impl.sql.GenericPreparedStatement.execute(GenericPreparedStatement.java:297)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeStatement(EmbedStatement.java:1235)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.executeStatement(EmbedPreparedStatement.java:1675)
> at
> org.apache.derby.impl.jdbc.EmbedPreparedStatement.execute(EmbedPreparedStatement.java:1330)
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
