Chapter 20. Persistent Object Store

Table of Contents
Creating and Accessing an Object Store
Commit Records
Defining Pivot Points
Reachability-based Persistence
Functions Reference

The persistent object store module (rs.db.rstore) is an implementation based on the concept of pointer swizzling at page-fault time as described in Paul Wilson's Pointer Swizzling at Page-Fault Time. This allows the system to access databases larger than the virtual memory of the machine, and with efficient translation costs (pages are faulted in and translated on-demand, and once faulted, incur no additional run-time overhead).

The underlying storage for the object store is log-structured (and, in fact, currently no mechanism exists to automatically or incrementally compact the log). Only one file is used to store all the information in an object store, and that file is called the backing store file.

The interior structure of an object store -- that is, the data structures which are stored -- are determined completely by the application program. This facility provides access to a single value per persistent store, the root object, which is read using the root-object function and written using the commit function.

Creating and Accessing an Object Store

The life cycle of an object store starts off with it's creation (obviously). A newly created object store has no contents, and takes up about 600 bytes in the backing store. The initial root object is #f.

Thereafter, a sequence of commit operations take place, each establishing a (possibly) new root object. Each commit copies all dirty pages (pages modified since the last commit) to the end of the backing store file, and then writes out a commit record which describes the state of the object store.

An existing object store is accessed using the open-persistent-store function.