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, 02 May 2005 20:53:25 GMT
I  like this name :  derby.system.durability=test

I will wait for Suresh's comments and then change the name of the 
property after that unless someone else has a better suggestion.

Thanks for your input.

David Van Couvering wrote:

> I think testMode isn't very clear what it's doing.  I agree that 
> relaxedDurability is not correct because it doesn't communicate that 
> you may not be able to boot the database.
> How about derby.system.fast-and-loose :)
> Seriously, how about
> derby.system.durability=test
> (you can't really say "none" because data pages are being written to 
> disk)
> or derby.system.durability.testMode=true
> I personally like derby.system.durability=test, because then later we 
> can add derby.system.durability=relaxed for true relaxed durability 
> where the database is durable, and derby.system.durability=none for 
> when we implement in-memory storage.
> David
> Sunitha Kambhampati wrote:
>> 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.

View raw message