db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Suresh Thalamati <suresh.thalam...@gmail.com>
Subject Re: [jira] Commented: (DERBY-298) rollforward will not work correctly if the system happens to crash immediately after rollforward backup.
Date Wed, 25 May 2005 23:54:42 GMT

Øystein Grøvlen wrote:

>>>>>>"ST" == Suresh Thalamati <suresh.thalamati@gmail.com> writes:
>>>>>>            
>>>>>>
>
>    ST> derby has two types  of log files , one that works  in RWS mode with a
>    ST> preallocated log file ,
>
>What is RWS mode?
>  
>
RWS mode is  writing transction log using  the write sync mechanism 
supported by java.io.RandomaccessFile  from  jdk1.4.2  onwards, when a 
file is opened with "rws"  , all  writes to the file are synced to the 
disk on the write call itself.

>    ST> and  one which  uses  file sync  with  out preallocation.  In case  of
>    ST> preallocation  , zeros  are  written to  the  log file  to the  length
>    ST> specified  by the logSwitchInterval  (Default is  1 MB)  , it  is also
>    ST> configurable by the user.
>
>What determines which mode is used? 
>  
>
Write sync is the default  mode when derby is run on jvm after 
jdk1.4.2.  users can also  specify the engine to use
file sync mode ,  for example to avoid Derby-1 problem on  Mac-OS. 


>    ST> This  problem  can  also  be  fixed  by  writing  dummy  log  record.  
>    ST> Filelogger.redo() code  has to be fixed to  understand this, currently
>    ST> it looks at the logEnd only when a good log records is read.
>
>I was thinking that the "dummy" log record should be a "good" log
>record so that the current implementation of redo() need not change.
>    ST> Another possible  solution I  was thinking to  identify whether  a log
>    ST> switch is good  or not is by writing  a INT (4 bytes of  zeros ) after
>    ST> log file  initialization. As 512 bytes  writes suppose to  be atomic. 
>    ST> if  (log file  length >  = LOG_FILE_HEADER_SIZE(24)  +4) then  the log
>    ST> switch before the crash can be fixed as good one and fix the scan code
>    ST> to use the empty log file instead of writing to the previous log file.
>
>I am not sure I understood this.  Do you suggest writing the INT just
>after the header? 
>
Yes.  If  the header is written to the disk completely,  then,  it is 
safe to say  log switch is  completed successfully.

Basically:
 1) Write the header  and do a file sync as it done currently.
 2) Wrie a INT(4 bytes of zeros)  and do a file sync.

On scan if  the log file size is  >=  LOG_FILE_HEADER_SIZE(24) +4 ,  
then the log file switch was successful  before the crash.
It can be used as the next log file.


> Would this work for preallocated log files?  
>
I think so,  preallocation is done only for performance reasons. For some reason  if  the
preallocation did not complete, recovery should work fine.  just that log writes will be slower
until the next switch. 


>Would
>not the length always be 1 MB (default) in that case?
>
>  
>
Not sure I understand this question completely. Length will not be 1MB 
(default) If the crash occurs after log file initialization , but before 
preallocation. It will  be just  LOG_FILE_HEADER_SIZE(24) +4 .


Thanks
-suresh




Mime
View raw message