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
