db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oystein.Grov...@Sun.COM (Øystein Grøvlen)
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 12:16:22 GMT
>>>>> "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?

    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? 

    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?  Would this work for preallocated log files?  Would
not the length always be 1 MB (default) in that case?

-- 
Øystein


Mime
View raw message