Thanks for the feedback.
�ystein Gr�vlen wrote:
<>Even if it is a bit late, here are some questions/commentsto this
patch and the follow-up patch for the test program:
- I am not sure about the value of this mode compared to a mode with
relaxed durability, but guaranteed consistency. The large
performance improvements comes from not syncing transaction
commit. How much extra performance do you really get from not
doing one sync per checkpoint?
I think both the options
1) derby.system.durability=test
2)actual relaxed durability with consistency and recoverability
are useful. I would probably use 1 for testing purposes and earlier
responses to the list seemed to indicate #1 was good to support.
I agree with you that #2 is a good and useful option to have and I think
other databases support this option.
<>
- Unless I am missing something, it does not seem more difficult to
implement the alternative that guarantees consistency. Do you
have any plans to do that?
I have filed a jira issue (Derby-306). But I am tied up with other
things at the moment so I dont have plans to do this right now.
<> - With respect to upgrade, does previous versions properly
initialize the spare byte in the log.ctrl file? Otherwise, one
could risk false detections on upgrade.
-- the spare byte (that I used in my initial patch) is initialized
correctly in previous version., but in the final patch per review
comments - the log control flags byte was used to store this flag and
yes it is initialized in previous versions correctly. So I think there
should not be any false detections on upgrade.
<>
- I am a bit sceptical to the value of having a test that tests that
this feature give a certain performance advantage. I have seen
that over time such tests often have false failures when run on
new platforms. I see that your latest patch addresses this.
However, should the performance of disk io increase beyond your
threshold, the test would not be able to detect any failures to
turn off syncing.I think that a performance regression test
would be better for this prupose.
Yes, you are right. The best way to detect issues with this case would
be a performance regression test. This test was (is) tricky :)
specially adding the timing part as a functional test.. But I think
currently what the test does will atleast send off an alarm if the
inserts take really long. I added lots of comments in the test and as
well as when the test might fail with warnings about it being
approximate times.
But since we dont require any perf test to be run when submitting
patches, I think maybe this test is probably ok for now ..
I welcome any suggestions on this to make it better..
Thanks,
Sunitha.
