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] Updated: (DERBY-4330) NullPointerException or assert failure when re-executing PreparedStatement after lock timeout
Date Sat, 01 Aug 2009 01:02:14 GMT

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


Mime
View raw message