[
https://issues.apache.org/jira/browse/DERBY-5660?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13231270#comment-13231270
]
Kathey Marsden commented on DERBY-5660:
---------------------------------------
I don't think the primary wombat database should ever be dropped and recreated
because 1) It is time intensive and would eliminate the performance advantage
of the JUnit tests. 2) The single database has been useful in upgrade/ soft
upgrade testing. Dropping it would cause the db to be recreated with the new
version and make that testing not possible.
> 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
