Implementations of the IRecordSequence interface can be used to read and write log records. When log records are appended to an implementation of the IRecordSequence interface, each one is given a unique sequence number. Sequence numbers are strictly monotonically increasing within a given record sequence. Sequence numbers from different record sequences are not comparable.
Two different implementations of this interface are provided by the FileRecordSequence and LogRecordSequence classes. The FileRecordSequence is a record sequence based on a single log file in the file system.
The LogRecordSequence class, on the other hand, provides an implementation of the record sequence interface on top of a Common Log File System (CLFS) log. In addition to the standard record-oriented features, it provides a policy model for avoiding log-full conditions, and multiplexing of clients on the same physical file. This class works with the LogStore class which provides an interface for directly manipulating and managing a CLFS log file. The relationship between the LogStore class and the LogRecordSequence class is similar to the relationship between a disk file and a FileStream object. The disk file provides the concrete storage, and has attributes such as length and last access time; the FileStream object provides a view on the file that can be used to read from it and write to it. Similarly, the LogStore class has attributes such as a policy and a collection of disk extents; the LogRecordSequence class provides a record-oriented mechanism for reading and writing data.
Unlike the file record sequence, a LogStore instance stores its data in a collection of disk extents, represented by LogExtent instances. The extents in a given LogStore instance are all of uniform size, and space is added to and removed from a LogStore instance in extent increments.
A LogStore instance can have policy associated with it, represented a LogPolicy instance. A policy dictates rules that the log will attempt to follow, such as maximum number of extents and minimum size, and instructions on growing or shrinking the LogStore under certain conditions. In addition, you can also control whether a LogStore instance is archivable or non-archivable.
Archivable logs have an “archive tail”, which is the lowest sequence number of data that has not been archived. In order to move the archive tail, you should:
Create a LogArchiveSnapshot that represents a snapshot of the data that must be archived together in order to have a consistent backup of the log.
Archive the data from the LogArchiveSnapshot.
Call SetArchiveTail with the last sequence number that was archived.
Applications which use System.IO.Log must be prepared to handle failfasts resulting from the infrastructure. In some scenarios, System.IO.Log does not use exceptions to communicate errors to an application. Instead, exceptions are used primarily for recoverable errors by which an application developer can act upon. However, failfasts will occur when further execution would result in corrupted or potentially unusable log files. When failfasts occur, no other application action is available to rectify the problem, and an application must be prepared to terminate. For more information on failfast, see FailFast.
|FileRegion||Represents a region of a file to be archived. This class cannot be inherited.|
|LogArchiveSnapshot||Represents a snapshot of the LogStore instance that can be used to generate an archive.|
|LogExtent||Represents a disk extent that contains log data.|
|LogRecord||Represents a log record that has been appended to a sequence.|
|ReservationCollection||Manages the collection of space reservations made in a record sequence.|
|ReservationNotFoundException||Represents the exception that is thrown when a specific space reservation in a LogRecordSequence is not found.|