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 Thu, 05 May 2005 23:31:54 GMT
Thanks Suresh for your comments.  I have attached a new patch that takes 
care of them and as well as the property name change as discussed on the 

So now,
1)To enable this no syncs mode, the property setting  is 
If it is set to any other value other than test, then this property 
setting is ignored and the system will default to the usual mode where 
all syncs happen correctly.
2) If database is booted in this mode then the  flag  to indicate this 
mode is being used is set in log.ctrl file and it will not change after 
that.Thus there wont be any switching between this mode ( no syncs) to 
default ( all syncs) mode because we cannot guarantee that the database 
will be in a consistent state once its booted in this no sync mode..
3) This  flag is now written out as part of the log control flags in 
log.ctrl file instead of using a spare byte.
svn stat:
M      java\engine\org\apache\derby\impl\store\raw\log\LogToFile.java
M      java\engine\org\apache\derby\impl\store\raw\data\RAFContainer.java
M      java\engine\org\apache\derby\iapi\reference\MessageId.java
M      java\engine\org\apache\derby\iapi\reference\Property.java
M      java\engine\org\apache\derby\loc\messages_en.properties

I use eclipse IDE and have it set to put 4 spaces for tab ( as per 
discussion on formatting on the list). I did verify by opening the files 
in viw  ( with tab set to 4) and the formatting looks ok.  But even when 
I sent the patch last time, in eclipse the formatting looked ok, so not 
totally sure what may be happening. But if  someone finds any issue with 
formatting please let me know.

Can someone review it and if it looks ok, can a committer commit it.  


Mike Matrigali wrote:

> <>I think that once the db is run in this mode it should be marked, and
> not worry about ever unmarking it. At first I just thought this was
> necessary to explain lost transactions, but I agree with the case below
> - successful recovery/booting does not guarantee consistent database.
> The case that you describe below can easily result in an index entry
> pointing to a non-existent base table row - with all the subsequent
> runtime errors later on.
> So I would lean toward changing to single flag, set once and never
> untoggled. .......

> <>Suresh Thalamati wrote:

>>Hi Sunitha,
>>Good comments. I am surprised to find that this patch doing more than
>>what I imagined  it will  do, your changes
>>seems to allow switching  between durable test mode(No syncs)  and the
>>default durability level (all sync).  I don't get why
>>these mode switch functionality is required, if this mode is just meant
>>to run the tests faster in non-durable mode! . Not sure what
>>kind of new problem  scenarios this mode switching will introduce.
>>But for some reason if some one wants,  I am not sure your fix will
>>actually make a non-durable database
>>to durable/consistent  one correctly.  What I learn   from your changes
>>is that  data is not synced to disk on checkpoints,
>>if you don't do that you can not assume database is is in consistent
>>state if  recovery went through fine.   Let's say:
>>1) user started the database with derby.system.testMode=true
>>2) did some insert/update/deletes ...
>>3) crashed immediately after the checpoint record got on to disk...
>>4) Now user switches derby.system.testMode=false and boot the database.
>>Recovery will  work fine because there is no log to replay.  So you
>>unmark the
>>Test mode flag in the control file and declare that this database is in
>>durable/consistent mode.
>>But that is not the case because only some  of the data pages might 
>>have reached to the
>>disk before the crash, Which will actually leave  the database
>>inconsistent state.
>>(This is different from losing some transactions).
>>Some general comments on the  code:
>>1) Why don't we just introduce a new flag private static final byte
>>    write as part of the "flags" byte  which is currently used to
>>indicate the IS_BETA_FLAG instead of using
>>    another spare byte.
>>2)  in few places indentation is not matching the rest of the code( 
>>that's how my emacs shows it):
>>   a)
>>            // if system is running with derby.system.testMode enabled
>>               // log records and log file are not synced, so
>>       // set flag to disable log syncs
>>  b)
>>                {
>>               // print message stating that the database was
>>           // previously running with derby.system.testMode=true
>>               // mode
>>  c)      if( wasDBInTestModeNoSync && !logNotSynced )
>>       {
>>       // write to log control file and the mirror file that the testmode
>>           // is not used now
>>  d)                 if(wasDBInTestModeNoSync)
>>           {
>>               // print message stating that the database was
>>           // previously running with derby.system.testMode=true
>>   ......etc.
>>3) I think the logical place for the method  private boolean
>>updateTestModeFlagInCtrlFile(byte value)
>>    is next to  writeControlFile(...) .
>>4) protected  logErrMsgForTestModeNoSync() may be marked as a private.
>>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
>>>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