db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sunitha Kambhampati <ksunitha...@gmail.com>
Subject Re: [PATCH] Derby 218 - Add relaxed durability option
Date Mon, 23 May 2005 03:03:07 GMT
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..


View raw message