|
OPJ Tutorial: IntroductionIn this section we will introduce the basic concepts behind Orthogonal Persistence for the Java platform (OPJ). We will present a simple example that demonstrates these concepts in action, and explain how to compile and run the application.Basic ConceptsThe basic idea behind OPJ is very simple, so simple in fact that people sometimes miss it because they are used to much more complicated models of persistence. The idea is this: imagine that a Java Virtual Machine is running an application consisting of a number of threads, a collection of loaded classes, and a heap of essentially unlimited size containing objects (class instances). Over time, threads may start and finish, objects might become unreachable and therefore eligible for garbage collection and new classes might be loaded (and unloaded), but a large majority of the heap objects represent information that has a very long lifetime. Now imagine that it is possible to save the state of this entire computation in such a way that it can be resumed at some future time, without any significant programming being required, and with all the invariants of the application and the Java Virtual Machine guaranteed to be preserved. That, in a nutshell, is what the OPJ platform aims to provide. We use the term checkpoint to describe the act of saving the computation and the term resumption for continuing the computation. A checkpoint is expected to be fast, proportional to the amount of data that has changed since the previous checkpoint, and independent of the total number of objects. The total number of objects is expected to be very large in the general case, much larger than could fit in a computer's main memory.A key part of the OPJ vision is that active computations can persist, which provides the illusion that applications continue running, even across a shutdown (planned or unplanned!) of the system. In the Java platform, supporting persistent active computations means two things. First that the code can be persistent and second that threads can be persistent. Making code persistent is relatively easy, but note that code persistence implies more than just being able to find the classfiles. The OPJ platform provides a guarantee that when the computation is resumed an object instance remains bound to exactly the same class that it was before the checkpoint. This means that the code of the methods and the values of the static variables of a class are persistent. If you are wondering whether it is ever possible to change the code (or other aspects) of a class, rest assured that this can be achieved using the OPJ evolution tools. Making threads persistent is a lot more difficult, particularly if the Java Virtual Machine uses native operating system thread support. Although we have some experimental prototypes that do support persistent threads, our current prototype for Solaris does not. This has an impact on the structure of certain applications, but there is often a simple workaround as we shall see below. The Persistent StoreIn the OPJ programming model, the persistent store provides the stable storage for a suspended computation. At a minimum, the store will contain all of the object instances, class instances and thread instances that were persistence reachable at the time of the last successful checkpoint operation. Persistence reachability is a slight modification of the normal rules for reachability that takes into account the transient modifier. The persistent store may also contain objects that are no longer reachable, and these will eventually be garbage collected.Because the persistent store contains a complete suspended computation, application programs neither create nor open persistent stores explicitly. Instead, the OPJ Virtual Machine is launched with a persistent store as an argument and, after performing possible crash-recovery actions, resumes the computation as if it had never paused. The special case of an empty (new) persistent store is detected automatically and does not require any additional work by the programmer or user. This programming model is rather different from that for traditional file-based applications, and most other persistence mechanisms for the Java platform, even those based on object-oriented databases. As a result, it may take a little getting used to, but the programer benefits by not having to write the tedious and repetitive code that manages the opening of the store, with all the attendant error handling that is required. The way that the store is specified to the OPJ Virtual Machine is implementation dependent, but is generally is through a name that directly or indirectly identifies the location of the persistent store. The details for the current release can be found here. CheckpointsThe state of the computation is stabilized to the persistent store whenever the OPRuntime.checkpointmethod is invoked. Stabilization is atomic, that is, it either succeeds completely or not at all. The stabilization will consider all objects that are persistence reachable. The Java Language Specification defines that an object is reachable if a reference to it can be reached by tracing references from special root objects, notably the active threads and the bootstrap classes. If thread persistence is not supported, persistence reachability is defined solely in terms of the bootstrap classes as roots.The OPRuntime.checkpoint method may also be invoked implicitly as a consequence of a normal termination (shutdown) of the OPJ Virtual Machine. A normal termination can occur in three ways:
Abnormal termination occurs when the exit method in the Runtime or System class is invoked with a non-zero argument , or when the last non-daemon thread exits with an unhandled exception. In this case no implicit checkpoint occurs and all updates since the last successful checkpoint, if any, are lost. In the next section we will construct a simple example program to demonstrate the concepts introduced in this section.  PREV:
Setting up the Environment,  NEXT:
A Simple Example,
Tutorial Home
Page
Last changed: Nov 15th 1999 Questions and comments to forest-info@sunlabs.com | ||||||||||||||||||||||
