[
https://issues.apache.org/jira/browse/DERBY-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5406:
--------------------------------------
Attachment: d5406-2a-invalidate-self.diff
Attaching patch 2a which makes FromBaseTable.bindNonVTITables() invalidate the
statement itself when it discovers that the conglomerate has disappeared. That
way, if the conglomerate was dropped between buildTableDescriptor() and
createDependency() so that the original invalidation was lost, we'll still
invalidate the statement and make GenericPreparedStatement.executeStmt() detect
that a recompilation is needed.
I've run four parallel instances of the D4275 test case for 1.5 hours without
seeing any instances of stack trace (2) mentioned in an earlier comment. That
stack trace usually reproduces in 2 to 5 minutes on the same machine without
the patch.
A very similar stack trace was seen three times in those 1.5 hours. That
exception was thrown at the exact same place in FromBaseTable, but the
re-compilation had been started at a lower level, from GenericActivationHolder,
instead of directly from GenericPreparedStatement.executeStmt().
I think the reason why it still fails if the compilation was started at a lower
level, is that the self-invalidation introduced by this patch is ignored
because it happens while the statement is being compiled. This was the exact
same problem as the one addressed by the 1b patch. However, the 1b patch only
added logic to retry compilations started directly from
GenericPreparedStatement.executeStmt(). So it looks like the retry logic from
1b must be enhanced to cover more cases.
But, in any case, I think the 2a patch is an improvement on its own. It makes
the failures happen less frequently, and I haven't noticed any new failures
because of it.
The full regression test suite is currently running. I plan to commit the patch
if all the tests pass, and then I'll go on trying to fix the retry logic for
the cases that are still missed out.
> Intermittent failures in CompressTableTest and TruncateTableTest
> ----------------------------------------------------------------
>
> Key: DERBY-5406
> URL: https://issues.apache.org/jira/browse/DERBY-5406
> Project: Derby
> Issue Type: Bug
> Components: SQL
> Affects Versions: 10.8.2.0, 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: d5406-1a-detect-invalidation-during-compilation.diff,
> d5406-1b.diff, d5406-2a-invalidate-self.diff
>
>
> The test cases CompressTableTest.testConcurrentInvalidation() and
> TruncateTableTest.testConcurrentInvalidation() fail intermittently with
> errors such as:
> ERROR XSAI2: The conglomerate (2,720) requested does not exist.
> The problem has been analyzed in the comments on DERBY-4275, and a patch
> attached to that issue (invalidation-during-compilation.diff) fixes the
> underlying race condition. However, that patch only works correctly together
> with the fix for DERBY-5161, which was backed out because it caused the
> regression DERBY-5280.
> We will therefore need to find a way to fix DERBY-5161 without reintroducing
> DERBY-5280 in order to resolve this issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
