db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Van Couvering <David.Vancouver...@Sun.COM>
Subject Re: [PATCH] Derby 218 - Add relaxed durability option
Date Mon, 02 May 2005 18:26:04 GMT
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.
>>>>
>>>>
> 

Mime
View raw message