Writing Data Safely with the CKPTFile Class

sing memory-mapped files can get you tremendous performance gains, but memory-mapped files are very delicate: any change is immediately reflected in the filesystem. This article describes a checkpointing system that lets you make atomic changes to a memory-mapped file, using techniques borrowed from the world's commercial relational databases.

This allows you to benefit from the tremendous speed and flexibility of memory-mapped files and at the same time feel confident that your application is robust, even in the event of a catastrophic failure.

Delicate Data
Data is very delicate. We rely on sophisticated techniques to keep it safely on our disk drives, and most of the time we don't have to think about it. But when you're the one writing the software that manipulates the data, then you do have to think about it.

Figure 1. Editing a File: Two versions of the file exist in the same computer—the original one stored on disk, and the new one residing in memory.

Let's consider a scenario using a common business application a word processor. When a user opens a document and makes some changes to it, there are, at that moment, two different versions of the document: one in memory and one on disk (see Figure 1).

Let's imagine that our word processor—and the underlying operating system—are written naively. You might imagine that when the user hits "Save," such an application would immediately begin to write the new file over the old one (see Figure 2).

If the save process completes, this works fine. However, what if power fails in the middle of the process? The user winds up with a file that comprises half of the original version and half of the new version. Not only does he lack a single complete version, but the file itself might be too corrupt for the word processor to read, in which case, the user will have nothing at all.

Figure 2. Saving Naively: The word processor saves the file directly over the original one.