db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Rick Hillegas (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4330) NullPointerException or assert failure when re-executing PreparedStatement after lock timeout
Date Tue, 04 Aug 2009 18:40:14 GMT

    [ 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.


Mime
View raw message