Persistent systems allow data to be manipulated as if it were always available in program memory. Data persists even after a program has terminated and is thus independent of the lifetime of a program. (cite something on persistence). A persistent system is typically some sort of execution engine (an interpreter) coupled with a persistent store. If there is no interpreter and compiled code is being used, the program will have had to be linked with libraries that access the persistent store.
The task of storing runtime data onto permanent storage (such as a file on a hard disk) requires some sort of mapping between the runtime representation of the data and the storage space. In the case of object-oriented languages and particularly in the case of Persistent Java implementations [1] [8] it is desirable to map objects into the store. To do this the persistent store will likely expose an interface that allows new objects to be created and existing objects retrieved or updated.
Our aim is to separate the persistent system into at least two pieces: an execution unit and the persistent store. It is important to distinguish the point where data is no longer perceived as an object but only as an array of bytes. Many persistent stores blur this distinction because the physical storage isn't distributed and is accessed in a platform-specific way.