Falcon uses a Serial Log to hold certain types
of information before that data is finally committed to the
database. The log is used to store the following types of
information:
Data records during the commit phase.
Physical database changes required for data recovery after a crash.
Logical database changes required for resource recovery after a crash.
Transaction state changes for all active transactions (active to committed, active to rolled back, active to limbo).
All transactions within Falcon are written to
the Falcon Serial Log and then committed to the
database, either automatically when
autocommit is enabled, or
manually when the COMMIT command is
used.
Logging information is stored in memory and unwritten changes to the log are periodically flushed to disk. A background thread processes the contents of the log, committing the log changes to the database. The commit process sets the final status of all records and pages, regardless of any intervening states; only the final state is actually written to disk.
Note, however, that the serial log commit process only updates the record data through the in-memory page cache. The actual record data will be written to disk when the checkpoint process occurs. The exception to this rule are index and log entries, which are immediately written to disk as part of the commit process.
Falcon creates two serial log files. The first
log file is used to store the serial log data until the log
reaches a specified size. Once that size has been reached, logging
is switched to the second serial log file. The commit process
continues to read from the first log file until all transactions
have been written to the database. The first log file is then
released and recreated.
Log entries in the second file are then processed until all transactions in the log have been completed. That file is then released and recreated, ready to be pressed into use as soon as the first log file is full or becomes locked for commits.
