2.1 Persistence in Applications

The principal tenet of persistence is to save something to non-volatile storage, which can be a file, a disk, or flash memory, such that if a system is power cycled or an application is restarted, it is possible to retrieve what was previously stored.

A persistence mechanism can either be implemented by an application itself or can be made persistent magically by the operating system, for instance. Thanks to object-oriented programming, it is easy to implement the first case in a helper class that can read and write all basic types like int , short , byte , boolean , String , Date , and so on.

Such a helper class works as an adapter between the storage media and the object contents. If an interface is used for all classes that should become persistent, it is also easy to make a closure of objects persistent and to read the state back into memory. We drill more deeply into this approach later.

The other way to load and save the object state persistently can be implemented by the runtime system, the operating system, or in case of Java, by the virtual machine. The idea is that this environment already has all the information about the memory layout of objects, their references to other objects, and so on. It just needs to copy a chunk of data to or from a disk. This kind of fully orthogonal persistence can become difficult to realize because the underlying runtime or operating system cannot properly restore semantics without a notion of surrounding application environment. Examples of such persistence-incapable types are network connections (sockets), file handles, or window positions .

In the past, several vendor-neutral groups have tried to solve and propose standards for the persistence problem: Project Forest (Sun's Orthogonal Persistence research project), Java Blend, Object Data Management Group (ODMG), EJB CMP, and many others.