db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (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 21:20:14 GMT

    [ https://issues.apache.org/jira/browse/DERBY-4330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12739172#action_12739172
] 

Dag H. Wanvik commented on DERBY-4330:
--------------------------------------

Thanks for looking at this so quickly, Rick!

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

That is correct.

> 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().

This could be done, sure. However, can you see a scenario where an
error at close time would be retryable (like time-out at open time) ?

As the code in the patch currently stands, it does not check if the
exception is a a retryable one, admitted, it just goes ahead and
closes the child result set(s). In addition to time-out, I imagine
dead-lock would be a possible candidate candidate, as well as missing
permissions (which is why the new defensive code does not check for
time-out explicitly).

> 
> 2) Have the ResultSet call its own close() method if an error occurs
> during open().

What I did for now, was to make sure the open method does not mark the
result set as open before all other actions have been successfully
performed, cf. the change to UnionResultSet. Would calling close() in
addition add value to my approach? 
(I was hesitant to apply to much "power", here without understanding if it's needed :)

Perhaps, for those result sets which also make calls to getNextRowCore before they complete
openCore (e.g. GroupedAggregateResultSet) need some extra logic
like that typically contained in close, like e.g. clearCurrentRow, i.e. there is more state
to roll back than just closing the underlying result sets. I'll have a look..



> 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