db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Matrigali <mikem_...@sbcglobal.net>
Subject Re: [PATCH] Derby 218 - Add relaxed durability option
Date Mon, 02 May 2005 21:36:27 GMT
this seems fine with me.  I agree none does not seem right, none seems
more appropriate if an in memory implementation is ever provided -
though derby.system.durability=memory seems better than none in that

I like that a setting that says "test" forces someone to think about
what they are setting - and hopefully look up what the consequences
can be.

Sunitha Kambhampati wrote:
> 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.
> Sunitha.
> 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
>>>>>>> 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
>>>>>>> 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
>>>>>>> could have happened because of this mode being set.

View raw message