db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (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 Fri, 16 Mar 2012 15:25:39 GMT

    [ 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

        

Mime
View raw message