[
https://issues.apache.org/jira/browse/DERBY-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231288#comment-13231288
]
Kristian Waagan commented on DERBY-5660:
----------------------------------------
+1 on reporting "final errors", i.e. the errors occurring during the last
iteration.
If we assume that there won't be any such problems normally, I guess we can
issue some ALARM statements? Failing the test/suite seems a bit strict to me,
but that's also a possibility.
Once this has been implemented one may have to take care of existing issues in
the tests, and potentially improve the cleaning logic in CleanDatabaseTestSetup.
> CleanDatabaseTestSetup should report the errors if the database object
> dropping does not succeed. An alternative could be to drop and create a brand
> new db if db objects from existing datbase runs into errors.
> -----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5660
> URL: https://issues.apache.org/jira/browse/DERBY-5660
> Project: Derby
> Issue Type: Improvement
> Components: Test
> Reporter: Mamta A. Satoor
>
> While working on DERBY-5638, we found that CleanDatabaseTestSetup decorator
> can run into lock time out issues while trying to drop database objects and
> hence those objects do not get dropped. If there is a subsequent suite using
> the same database, it will go through CleanDatabaseTestSetup's drop objects
> sequence again, run into lock timeouts again and when it ties to next create
> the database objects required by the next suite, it may run into Table/View
> 'ObjectName' already exists in Schema 'SchemaName'. None of the errors
> received during the object dropping attempts get reported and hence there is
> no way of knowing that CleanDatabaseTestSetup had trouble cleaning up the
> database.
> One solution as suggested by Dan Debrunner in DERBY-2220 a very long time ago
> could be
> ******************
> I also think that you've found an issue in the clean database decorator and
> as
> such it would be good to fix it centrally there, rather than in a single
> test.
> for example, if the clean database decorator failed to cleanup the database,
> it could report the failure and then blow away the database.
> ******************
> Knut also suggested following in DERBY-5638.
> ******************
> 1) Wait for post-commit to finish after having deleted the rows. This can be
> done by calling T_Access.waitForPostCommitToFinish() in a stored procedure
> after deleteTable(). See ReleaseCompileLocksTest for an example.
> 2) Use TRUNCATE TABLE instead of DELETE in the deleteTable() method. In
> addition to being faster on large tables, it also avoids post-commit work and
> shouldn't cause any concurrent locking to happen during tearDown().
> ******************
> Knut's suggestions above were made for the actual test and not the decorator.
> But I think we may be able to use them in CleanDatabaseTestSetup. Will
> require more research if CleanDatabaseTestSetup can actually implement these
> because when the control is with CleanDatabaseTestSetup, we are no more in
> the user transaction and hence there may be no way of waiting for post-commit
> of that user transaction to finish.
--
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
