[
https://issues.apache.org/jira/browse/DERBY-5406?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Knut Anders Hatlen updated DERBY-5406:
--------------------------------------
Issue & fix info: (was: Patch Available)
Committed d5406-4a-push-retry-logic.diff to trunk revision 1190220.
Then there's hopefully just one single exception left to fix before we can
declare victory on this issue (see comment dated 26/Oct/11 16:35). I added some
instrumentation and found that the statement did not have the
invalidatedWhileCompiling flag set, which means that it wasn't retried because
the invalidation was lost somehow.
My guess is that its cause is similar to the case fixed by patch 2a. The
statement is invalidated after we have built the table descriptor, but before
we have registered the statement as a dependent of the table. However, contrary
to the case fixed by 2a, the conglomerate isn't actually removed before we
fetch the conglomerate descriptor, so the self-invalidation logic we added to
the error handling when the conglomerate descriptor is missing, doesn't help in
this case. The conglomerate is removed a little later, though, so the
compilation will fail, but without the invalidation flag set, the compilation
will not be retried.
I'm wondering if a more robust approach would be to retry the compilation
always if it fails because of a missing conglomerate. That's an error that will
never be reported to the user unless there's a bug in Derby, I think, so
retrying the compilation in those cases shouldn't be a problem. And if we get
an error about the same conglomerate missing on the retry, we could report it
to prevent infinite loops in case there actually is a problem that must be
reported. In the case of a concurrent compress or truncate operation, we should
find the new conglomerate when retrying. If the conglomerate is missing because
of a drop operation, the recompilation will fail, but it should fail earlier
because the system tables have been updated with the correct information, and
the error message will be more informative (typically: "Table T does not exist"
instead of "Conglomerate X does not exist").
> 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.2, 10.9.0.0
> Reporter: Knut Anders Hatlen
> Assignee: Knut Anders Hatlen
> Attachments: CompressAndPrepare.java,
> d5406-1a-detect-invalidation-during-compilation.diff, d5406-1b.diff,
> d5406-2a-invalidate-self.diff, d5406-3a.diff, d5406-4a-push-retry-logic.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
