[
https://issues.apache.org/jira/browse/DERBY-4585?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-4585:
--------------------------------------
Attachment: fix.diff
The problem seems to be related to the caching of updatable index scans in the
activation (the NPE happens because the cached scan is null). The field that
holds the cached scan is initialized by TableScanResultSet.openCore() if, and
only if, the scan is updatable and uses an index. However,
TableScanResultSet.close() unconditionally clears the information. So if a
statement execution plan has one updatable index scan and one non-updatable
scan, closing the non-updatable scan may clear information needed by the still
open updatable scan.
The attached patch ensures that TableScanResultSet.close() only clears index
scan information from the activation if it had cached information there itself.
This made the NPE go away. The patch does not include any tests, and I have not
run any of the regression tests with it yet.
(By the way, I don't think this problem was introduced with DERBY-3301, but it
probably made the optimizer pick a different plan (it changed how nested
IN/EXISTS queries where flattened, I think) that made the problem surface. It
may be possible to come up with a case that fails before DERBY-3301 too.)
> IndexChanger.doDelete throws NullPointerException
> -------------------------------------------------
>
> Key: DERBY-4585
> URL: https://issues.apache.org/jira/browse/DERBY-4585
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.5.3.0
> Environment: Various operating systems, Java 1.6.0_18
> Reporter: Martin Keller
> Assignee: Knut Anders Hatlen
> Fix For: 10.3.3.0, 10.4.1.3, 10.4.2.0, 10.5.1.1, 10.5.2.0,
> 10.5.3.0, 10.6.0.0
>
> Attachments: derby-4585.tar.gz, fix.diff, repro.sql, repro.zip
>
>
> After a bunch of DELETE and DROP-Commands, the following error occurs in our
> application:
> 2010-03-16 12:54:23.070 GMT Thread[DRDAConnThread_4,5,derby.daemons] (XID =
> 15898), (SESSIONID = 1), (DATABASE = ixintrexx), (DRDAID =
> NF000001.PAA8-4469821361421447518{2}), Cleanup action starting
> 2010-03-16 12:54:23.070 GMT Thread[DRDAConnThread_4,5,derby.daemons] (XID =
> 15898), (SESSIONID = 1), (DATABASE = ixintrexx), (DRDAID =
> NF000001.PAA8-4469821361421447518{2}), Failed Statement is: DELETE FROM
> LCAPPCHILDCONTROLTITLE WHERE STRCHILDCONTROLGUID IN (SELECT STRGUID FROM
> LCAPPCHILDCONTROL WHERE STRAPPCONTROLDRGUID IN (SELECT A.STRGUID FROM
> LCAPPCONTROLDR A, LCAPPFUP B WHERE A.STRAPPFUPGUID = B.STRGUID AND
> B.STRAPPGUID = '93A720B90BB6C25703701E67D0DA75220B7D2FFC'))
> java.lang.NullPointerException
> at
> org.apache.derby.impl.sql.execute.IndexChanger.doDelete(IndexChanger.java:369)
> at
> org.apache.derby.impl.sql.execute.IndexChanger.delete(IndexChanger.java:544)
> at
> org.apache.derby.impl.sql.execute.IndexSetChanger.delete(IndexSetChanger.java:250)
> at
> org.apache.derby.impl.sql.execute.RowChangerImpl.deleteRow(RowChangerImpl.java:476)
> at
> org.apache.derby.impl.sql.execute.DeleteResultSet.collectAffectedRows(DeleteResultSet.java:405)
> at
> org.apache.derby.impl.sql.execute.DeleteResultSet.open(DeleteResultSet.java:137)
> 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.EmbedStatement.execute(EmbedStatement.java:625)
> at
> org.apache.derby.impl.jdbc.EmbedStatement.executeUpdate(EmbedStatement.java:175)
> at
> org.apache.derby.impl.drda.DRDAConnThread.parseEXCSQLIMM(DRDAConnThread.java:5022)
> at
> org.apache.derby.impl.drda.DRDAConnThread.processCommands(DRDAConnThread.java:750)
> at
> org.apache.derby.impl.drda.DRDAConnThread.run(DRDAConnThread.java:290)
> Cleanup action completed
> The database seems to be corrupt, after this exception has been thrown.
> As you can see, I already compiled Derby to get the line number where the
> error occurs. I must apologize for not having a sufficient test case yet, but
> the code leading to this issue is very complex. If one wants to reproduce
> this bug, I can send a download link for our product and instructions to
> reproduce the problem.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
