Persistent Object State Management in LegionReport
The persistence model for the Legion object-oriented wide-area metasystem is described. This model defines the protocols and mechanisms that are used to deactivate, reactivate, and migrate persistent objects within Legion. The persistence model requires the cooperation of three key entities: the persistent object itself, which is responsible for saving and restoring its volatile state on deactivation and reactivation, respectively, Vault Objects, special Legion Core Objects that manage the persistent states of inactive objects, and Legion Class Objects which manage the association between their persistent instances and Vault objects. The basic goal of the Legion project is to construct a wide-area, high-performance metasystem capable of providing a usable programmer interface to the increasingly complex nation-wide computing and communications infrastructure. The basic unit of program composition and scheduling in Legion is the active object, and the programming interfaces supported by Legion are object-oriented. Objects in Legion are logically address-space disjoint, and reside in a single unified name-space managed by a set of Legion Core Objects. The primary mode of object interaction is method invocation. Legion objects may be persistent in nature, retaining state and responding to methods indefinitely beyond the lifetime of the object that created them. The Persistent State of a running Legion object can consist of data in memory, pending results of member function invocations on other objects, unserviced member function invocations from other objects, mass storage resources (e.g. open files), graphical display resources (e.g. terminal windows), as well as many other operating system and hardware platform dependent resources. Since Legion objects are active, the state of an object may also include run-time data such as the call stack and register values of the objects threads of control. Persistent Object State Management in the context of Legion is defined to be the ability to capture the state of a Legion object into a linearized, transportable, and possibly architecture independent form, and conversely to reconstruct the state of a running object based on a previously captured state. A general purpose protocol for persistent object state management is central to a number of basic Legion attributes and services. First, the number of persistent objects in the Legion system at any point in time will certainly exceed the number of running objects which could be efficiently supported by the hardware infrastructure available to the system. The ability to move objects from Active to Inert states will be central to the scalability of Legion object scheduling services. Beyond this basic issue of scalability, a number of important Legion services could utilize object state management facilities. For example, some fault tolerance schemes are based on the ability to checkpoint the state of a running application and later restart needed program elements in case of failure. Another example is dynamic load balancing through object migration, which addresses the issue of achieving good application performance in the face of shared-resource environments. This document describes the design of the fundamental protocols and mechanisms used within Legion for persistent object state management. In Section 2 we provide a general overview of the Legion persistence model and introduce the key terms and object classes. In Section 3 we examine the role thatobject's 1 -
Note: Abstract extracted from PDF text
All rights reserved (no additional license for public reuse)
Ferrer, A, and A Grimshaw. "Persistent Object State Management in Legion." University of Virginia Dept. of Computer Science Tech Report (1995).
University of Virginia, Department of Computer Science