db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@Sun.COM (Øystein Grøvlen)
Subject Re: [PATCH] Derby 218 - Add relaxed durability option
Date Fri, 20 May 2005 23:23:29 GMT
>>>>> "SK" == Sunitha Kambhampati <ksunithaghm@gmail.com> writes:

    SK> A little background: Sometime earlier on the list, Dan posted a fix to
    SK> make derby  go faster  with relaxed durability  with some  flags. The
    SK> post                               is                               at
    SK> http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durability

I was originally planning to review this before it was committed, but
I did not get around to sending my comments before I went on a
vacation.  Even if it is a bit late, here are some questions/comments
to 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?

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

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

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

  - The test will only test whether the syncing at commit is turned
    off.  The other syncs will not decrease performance so much that
    it would be detected by the threshold of the test.


View raw message