This patch disables syncs for
- 1)the log file at each commit
- 2)the log file before data page makes it to disk
- 3)data page allocation when file is grown
- 4)data writes during checkpoint.
Thus, when this mode is enabled, syncs are not enforcing proper WAL
protocol and might lead to database not being able to boot.
Also earlier when I did a search on the web for the term relaxed
durability , it seemed to me that the term was used for cases when it is
ok to lose committed transactions but the database should be able to
boot successfully.
So does derby.system.testMode seem ok given that it might not be
appropriate in a production like environment...
Or, maybe another name -
call this mode of no syncs as derby.system.durable=none ( or
derby.storage.durable=none).
and in the future when someone implements the case that was discussed
earlier on list
(http://mail-archives.apache.org/mod_mbox/db-derby-dev/200504.mbox/%3c425C6489.4070205@sbcglobal.net%3e
) where only #1 and #3 syncs are disabled, that would ensure that
database would boot ok, with losing some committed transactions, this
setting could be derby.system.durable=partial or something similar.
Any comments.
Thanks,
Sunitha.
David Van Couvering wrote:
> After I wrote my email, I wondered if the feature as currently
> implemented wasn't quite what I was thinking we should have. I agree
> that if you potentially can't boot your database, this is not a
> production-level feature.
>
> I second the motion to see more work done to implement the relaxed
> durability option that guarantees a bootable database, that's what I
> was thinking of when I sent my previous email.
>
> Thanks,
>
> David
>
> Mike Matrigali wrote:
>
>> As I have posted before I have concerns about this mode, as it can
>> definitely produce a database which can not boot. But the discussions
>> here convinced me
>> that it was useful for a number of applications, so now believe it
>> should be checked in. I definitely have no career path in marketing
>> as my first take at a name was corrupt_your_db=true :-) . So testMode
>> seemed ok to me, but if another name is better that is fine with me
>> also.
>>
>> Going forward I would like to see more work done to implement the
>> relaxed durability option suresh and I were discussing. I believe
>> that with some code changes file allocation, log write and many of
>> the data write sync's can be eliminated and still guarantee a bootable
>> database. This mode would not guarantee a committed transaction,
>> but would guarantee that database on a disk with enough free space
>> would boot and that the db would represent only complete transactions
>> (either fully applied or not). This option would
>> be slower than what is available from this patch so I believe both
>> features are useful.
>>
>> David Van Couvering wrote:
>>
>>> Hi, Sunitha. Thanks for your work on this. My comment is more a
>>> "marketing" comment than a technical one. I disagree that this is
>>> useful only for testing and development. As I mentioned in previous
>>> emails, there are a number of customers who may find this very
>>> useful indeed, who are willing to trade off 100% guarantee of all
>>> transactions being available on recovery for significant increases
>>> in performance.
>>>
>>> I wouldn't get into this debate were it not for the fact that the
>>> property you have created is called "testMode." I would much rather
>>> have it not imply it's only for testing, with a name like
>>> "delayedWrite" or "relaxedDurability" or some such.
>>>
>>> Thanks,
>>>
>>> David
>>>
>>> Sunitha Kambhampati wrote:
>>>
>>>> A little background: Sometime earlier on the list, Dan posted a fix
>>>> to make derby go faster with relaxed durability with some flags.
>>>> The post is at
>>>> http://article.gmane.org/gmane.comp.apache.db.derby.user/681/match=relaxed+durability
>>>>
>>>> This mode is very useful for unit testing or at development time
>>>> when recoverability is not required.
>>>> Basically in this mode, syncs are disabled for logs, data writes at
>>>> checkpoint, page allocation when file is grown; - what this means
>>>> is that data is not flushed all the way to the disk and in most
>>>> cases i/o cost is not involved. Note, code already exists in Derby
>>>> to do this.
>>>> So for Derby 218, This patch addresses the following
>>>> requirements: 1) Have a single property to enable this relaxed
>>>> durability mode, so it is easy for users to enable it.
>>>> 2) Print message to derby.log that this mode is enabled
>>>> 3) A way to report boot errors that may be because of this option
>>>> being enabled. What this maps to is - have a marker to recognize
>>>> that database was booted in this mode, and then on subsequent boot;
>>>> if errors happen during recovery - report a message that it could
>>>> have happened because of this mode being set.
>>>