db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mike Matrigali (Commented) (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (DERBY-5382) Convert existing harness recovery tests to JUnit tests
Date Thu, 23 Feb 2012 21:04:55 GMT

    [ https://issues.apache.org/jira/browse/DERBY-5382?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13215049#comment-13215049

Mike Matrigali commented on DERBY-5382:

comments on reviewing latest patch.  This change is definitely an improvement, but still does
not match what the original test
was doing.   The best case would be if this test created a new database in the first forked
call and did the work below, then the
exact work would be tested. But not sure if current harness can do that.  I would suggest
first making the changes below and 
checking in, then work on executing in a separate db.  Maybe others can help with the separate
db issue.  If you don't want to deal
with comment issues, let me know and I can add some after you check in - i don't want to conflict
at this point.

In the original test the following actions are performed in oc_rec1, and then a hard ("non
clean shutdown") is performed.
        beginTest(conn, test_name);
        createAndLoadTable(conn, true, table_name, 5000, 0);
        executeQuery(conn, "delete from " + table_name, true);
        callCompress(conn, "APP", table_name, true, true, true, true);
        endTest(conn, test_name);

The important part of this is that the create, delete, and compress log records will all be
processed by restart recovery when oc_rec2
is executed.  And also of interest is all the work to create the database also is in the log
of unclean shutdown, this also presents
interesting code paths for restart recovery.

In the current patch the createAndLoadTable(tableName, true, 5000, 0) is done and then a clean

If you can't figure out a way to have a new database created in the forked process, then please
log an issue for adding harness support
for that, as it would be good to be able to test restart recovery on a newly created db.

As a good incremental work around for your test I would move the createAndLoadTable(tableName,
true, 5000, 0); call from 
testOCRecovery_1() to launchOCRecovery_1().  This still will not result in the same codepaths
tested, but it will be closer.  Maybe add
in a extra create table of some dummy table, to make the session not read only.  At least
the clean shutdown with no work will lay down a checkpoint and make it less likely that dependent
on previous tests that a checkpoint
might happen during one of the phases and then we would skip the restart recovery work that
we are trying to test.

launchOCRecovery_2() is missing a few comments that are in oc_rec2()

comment in launchOCRecovery_3() is wrong (it was wrong in orignal also)
// setup to test redo recovery on:
// add more rows, delete rows, compress, add more, no commit

It should be:
// setup to test redo recovery on:
// add more rows, delete rows, commit,  compress, no commit

launchOCRecovery_4 is missing comments from oc_rec4

> Convert existing harness recovery tests to JUnit tests
> ------------------------------------------------------
>                 Key: DERBY-5382
>                 URL: https://issues.apache.org/jira/browse/DERBY-5382
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>            Reporter: Siddharth Srivastava
>            Assignee: Siddharth Srivastava
>             Fix For:
>         Attachments: DERBY-5382.diff, d5382.patch
> Existing harness recovery tests need to be converted to JUnit tests. A framework as designed
in Derby-4249 can be used for this purpose.
> Tests to be converted:
> a) oc_rec1
> b) oc_rec2
> c) oc_rec3
> d) oc_rec4
> These recovery tests run in coordination. The test oc_rec1 creates a table, inserts and
then deletes rows from it and commit it which is followed by a series of insertion of rows
in the existing table in oc_rec2, oc_rec3 and oc_rec4. The tests oc_rec2 and oc_3 also create
table and insert, delete, compress rows in it and leave the table thus produced in committed
or uncommitted state which is tested by the next corresponding test (oc_rec3 for oc_rec2,
oc_rec4 for oc_rec3) for recovery.

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


View raw message