RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Writing Data Safely with the CKPTFile Class : Page 4

Making changes to memory-mapped files is a delicate operation, but far from impossible. Learn how to make safe, atomic changes to memory-mapped files using a checkpoint system that will leave your applications fast and robust and your data impervious to corruption.

An Abstraction Layer
In order to make file access safer, the CKPTFile controls all access to the array. Instead of accessing the underlying array directly, you must go through the CKPTFile interface.

The underlying array is itself behind another abstraction barrier—in this case, it's hidden inside a MappedByteBuffer object. The CPKTFile uses the MappedByteBuffer to read and write the file (see Figure 4).

Figure 4. Our Various Buffers: The user uses a CKPTFile, which in turn uses a MappedByteBuffer, which contains the file array.

The get() methods read from the CKPTFile and the put() methods write to it. The get methods have a simple implementation—they just call the get() methods of the MappedByteBuffer. The put() methods are a little more complicated, and this is where we get to the heart of our implementation.

The Atomicity Architecture
The whole point of the CKPTFile class is to make it possible to checkpoint the file. This has the effect of turning the set of writes between two checkpoints into a kind of de facto transaction (see Figure 5). If the writes between two checkpoints are a transaction, then we want to carry out this transaction in its entirety or not at all. This means that in the event only some of the writes are completed, the file should be restored to its original state.

Figure 6 shows a hypothetical example in which a file is written and checkpointed. The first checkpoint occurs after a set of writes has been performed and completes successfully. The second set of writes begins, but before the second checkpoint can happen, the system crashes, leaving the file in an inconsistent state. The only thing to do in this scenario is repair the file so that it reverts to the state it was in just after the last checkpoint. How do you do that? The answer is surprisingly simple: get it from another file.

Figure 5. Checkpoints Imply Transactions: If we checkpoint the file at regular intervals the writes between two checkpoints can be thought of as a transaction.
Figure 6. Crash Before Checkpoint: Before a second checkpoint can happen, the system crashes, and the file must be repaired.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date