db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta A. Satoor (Created) (JIRA)" <j...@apache.org>
Subject [jira] [Created] (DERBY-5660) 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.
Date Thu, 15 Mar 2012 18:45:35 GMT
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

        

Mime
View raw message