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 Fri, 25 Jun 2010 21:43:57 GMT

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

Kristian Waagan commented on DERBY-4709:
----------------------------------------

Well, the first iteration of  testConnectionFlowCommitRollback gives you the count after [common_work]
(15 as the test stands now).
The second iteration of  testConnectionFlowCommitRollback gives you the count after ([common_work]
+ [unnecessary_commit_work]) (also 15 when the optimization works).
If these two counts differ, the test fails. Note that [common_work] and [unnecessary_commit_work]
are interspersed (in the second iteration of testConnectionFlowCommitRollback ), so there
isn't really a notion of before and after.
Before the fix for DERBY-4653, the second count was 340 (15+325).

If I add another query to the test sequence, the numbers will change. Thats why I first run
only [common_work] to obtain the base count, and then ([common_work] + [unnecessary_commit_work]).
If I used a hard-coded number for the base run, the test would be more sensitive to changes
in other areas of the code.
You can easily obtain these counts from the trace file manually during debugging. The trace
level can be changed from PROTOCOL to ALL (I'll do that in the next revision of the patch),
then it will be a lot easier to assoicate a commit flow with a JDBC call.


You are probably seeing the error because you are running on Windows. The behavior of the
file operations are different there, specifically you aren't allowed to delete a file when
it is open for reading.
Looking at the test and client driver tracing code, the real reasons are:
 1) I forgot to close the pysical connection (i.e. getPooledConnection() and getXAConnection()).
 2) There's a bug in the client driver tracing code, where the stream to the trace file isn't
closed.

I'll address 1 in the next revision of the patch, and will do Jira search for issue 2. If
I can't find that it has been logged, I will do so.


Thanks,

> 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: 10.7.0.0
>            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.


Mime
View raw message