db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Kristian Waagan (JIRA)" <j...@apache.org>
Subject [jira] Commented: (DERBY-4709) Create test that parse client trace file to detect round-trips for Derby-4653
Date Thu, 24 Jun 2010 06:57:54 GMT

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

Kristian Waagan commented on DERBY-4709:

Hi Lily,

Thanks for looking at the patch. Below are my answers to your comments. When I say commit
below, I mean both commit and rollback.

 1. That's a spelling error, yes. I'll correct it in an upcoming revision of the patch.

 2. I'm not sure I follow. Do you mean that we should correlate each commit flow to a JDBC
call in the test?
   Since the only thing differing between the base end the extra run of the test sequence
is the number of commits, my working theory has been that an increase in the number of commit
flows must be caused by the redundant commits.

 3. No, we only care about the fact that invoking commit redundantly doesn't cause more commit
commands to be flowed to the server.
   Without your fix for DERBY-4653, I think the base count was 13 and the extra count 339.
The test only compares these two numbers, expecting them to be equal if the optimization is
working. If an unrelated change causes Derby to flow two more commits for the test sequence,
it doesn't matter as it will apply to both the base count and the extra count.
   The trace file is not part of our public API. However, the token I've used comes from the
DRDA specification, and I don't see any reason why someone would change that. It has at least
remained unchanged since the code was donated to Apache.

If you enable the rollback-test and run the test you should hopefully see a reasonable failure

Now, the most annoying issue I've found so far is the fact that the support files directories
are deleted - which means that the trace file itself goes away...
Has anyone solved this problem before?

> Create test that parse client trace file to detect round-trips for Derby-4653
> -----------------------------------------------------------------------------
>                 Key: DERBY-4709
>                 URL: https://issues.apache.org/jira/browse/DERBY-4709
>             Project: Derby
>          Issue Type: Improvement
>          Components: Test
>    Affects Versions:
>            Reporter: Lily Wei
>            Priority: Minor
>         Attachments: derby-4709-1a-alternative_test.diff
> In DERBY-4653, Kristian suggested we have a test that parse the trace file to detect
round-trip Connection.flowcommit() instead of calling getClientTransactionID() method. The
existing test for DERBY-4653 is in J2EEDataSourceTest.testConnectionFlowCommit(). When this
issue get fixed, the call for getClientTransactionID can be replace with trace file parsing.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message