[
https://issues.apache.org/jira/browse/DERBY-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dag H. Wanvik updated DERBY-4330:
---------------------------------
Attachment: derby-4330c.stat
derby-4330c.diff
I upload derby-4330c, which uses the result sets' own close methods instead of
directly calling close on the underlying result sets, addressing Rick's point 2.
This should clean up any additional state, provided the close methods work
correctly in this (new) "half-opened" context. In my repro tests, the close
methods did the job and did not throw. I did inspect the result sets that have
additional state and it seems this should work OK provided the underlying close
methods don't throw, but I am not absolutely sure (Rick's point 1 is still not
addressed in the code).
> 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,
> derby-4330c.diff, derby-4330c.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.
