6.5 Limiting reachability based persistence

6.5.1 Special objects

For the primary intended usage, a special object is an object that is thought of as a single logical object that is always present in program executions using some persistent store. Support for special objects may thus be thought of as generic support for pointing out patterns that to some extend have only a single instance shared between all program executions using the pattern.

The state of special objects is never saved persistently. However, references to these objects should be saved so that they may be setup correctly when saved objects referencing a special object are re-instantiated in another process. Typical examples or special objects are application framework objects that are known to be present in the program executions exchanging persistent objects, but should not be saved themselves. Examples of application framework objects are instances of guienv, XtEnv, systemenv and shellenv. These application framework objects, of which there should be at most one in each program execution, are not to be saved persistently, but instances of patterns nested inside the application frameworks should be allowed to persist. As already mentioned, betaenv is always treated as a special object.

Special objects are registered once in the lifetime of a persistent store by supplying name and type of the object to the persistentstore.registerSpecialObject method. The type is saved in the persistent store in order to be used for type checking when registering special object instances as described below.

In addition to the initial registration, an instance of the special object must be supplied by each process using the persistent store by calling the persistentstore.registerSpecialInstance method when the persistent store has been opened, but before any get operations are made. The instance given to the registerSpecialInstance method must be a subtype ^[4] of the type given to the registerSpecialObject operation.

The demo program special.bet contains an example usage of special objects.

6.5.2 Runtime types

Runtime types are patterns whose instances are used at runtime, but should not persist across program executions. As mentioned in section 2, an example of this is interface objects such as windows. Another example is objects used for caching purposes at runtime and referenced from persistent objects although the cache objects themselves should not be saved across program executions. By registering the pattern p as a runtime type, instances of p are not saved during checkpoint operations even though they are found in the transitive closure of a persistent root. Instead references to these objects are saved as NONE references.

Runtime types are registered by calling persistentstore.registerRuntimeType. As runtime types registered using registerRuntimeType are not saved persistently in the store, registerRuntimeType must be called for each runtime type in each session using the persistent store in question. If needed, it is of course possible to save a table of runtime types in a persistent store. The demo program structdemo.bet is an example of how a table of pattern variables may be saved in a persistent store.

The demo program special.bet contains an example usage of runtime types.

6.5.3 Combining runtime types and special objects

Since references to special object instances are treated differently than references to instances of runtime types, it is a contradiction to register the same pattern as a special object and as a runtime type in the same persistent store. Doing so will result in a runtime error.

Furthermore, since it is not allowed to save an object without the knowledge that all its origins will be available when the object is to be reinstantiated, instances of runtime types should not be origins of objects saved. If an instance of a runtime type is needed as origin for some other object to be saved, the runtime type instance is saved anyway, disregarding the fact that it is an instance of a runtime type.

Different persistent stores used in the same program execution may have different sets of special objects and runtime types registered.