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 message.
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?