[
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-4330a.diff
This trial patch makes the repro work (not for commit). I agree result set
reuse is the problem here.
There are at least two JoinResultSets here (1 and 2 below) that are marked as
open, even when the parent ProjectRestrictResultSet is not so marked (since
openCore failed with the timeout).
So, at reuse time, the top level ProjectRestrictResult skips closing the
underlying JoinResultSet structure, because it itself is not marked opened. The
patch works around this by cleaning up children if openCore fails, effectively
undoing the setting of the isOpen flag.
1) The top JoinResultSet's openCore sets its isOpened flag *before* it attempts
to open the children result sets. This triggers the seen error when the result
set is reused (opened again).
2) Even if that is fixed by moving the setting of isOpened to the end of the
method, there is another problem: A lower level left result set does open
correctly, but right child result set in a join fails with the timeout. The
left one is thus already open at reuse openCore time. So just moving the flag
setting is not sufficient.
> 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
> Attachments: derby-4330a.diff, 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.
