db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Knut Anders Hatlen (Updated) (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (DERBY-5406) Intermittent failures in CompressTableTest and TruncateTableTest
Date Fri, 28 Oct 2011 09:50:32 GMT

     [ 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:,
>            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


View raw message