Abstract

Many applications use a log to store state, either to "redo" past actions, or to correct possible faults, errors or loss of consistency. A generic logging service should cater to the variable and even antagonistic needs of applications, without imposing overhead on applications which do not use all its functions. For instance, a transaction manager needs a different degree of reliability than a debugger. K i t L o g provides an original solution to this problem by decomposing and encapsulating logging functions. Five main mechanisms are distinguished: buffering policy, distribution of records, replication of records, sharing and multiplexing mechanisms, and management of physical media. Each mechanism is embodied in an object class. For each class, multiple policy implementations can be provided. Instances of these classes are stackable in any appropriate number or order. An application programmer customizes his logical log to a set of failure assumptions by selecting adequate class...

Citations