In the Mjølner System, objects generated by a BETA program
execution may be saved on secondary storage and restored in another
BETA program execution. Usually this property of a programming
language or system is referred to as object
persistence. Persistence in the Mjølner System is
based on a reachability model, meaning
that default behaviour when saving an object on secondary storage is
to save everything reachable from the object in question.
Mjølner supports a single-user persistent store model as well as a
multi-user shared persistent store. The multi-user persistent store
makes it possible to build an object-oriented database (OODB) using a
clienter/server model. Persistence in Mjølner is based on a number of
frameworks:
-
Basic persistent object management.
A program may saves its objects in a
persistent store and these may later be re-fetched from another or the same program.
This framework supports single-user persistence.
-
Concurrency control. If two or more programs (clients) need to
acces the same persistent store at the same time, it is possible to
synchronize acces to the persistent store through a server. The server
implements a concurrency control mechanism that mediates the access to
the persistent store. This framework supports multi-user persistent
store.
-
Transaction management.
Transaction management deals with the problem
of keeping a persistent store in a consistent state
when two or more clients concurrently access the store
or when failures happen during a program execution.
This framework adds functionality to a multi-user
-
Notification control.
When two or more clients use the same persistent store, a notification
mechanism is available for communication between the clients.
Notifications may be sent to cleints when e.g. objects are written
to the store by another client.
This framework adds functionality to a multi-user
persistent store.
In addition to the above main features, the following
features are also supported:
- The basic object management supports reference between objects in
different persistent stores.
- Recognizing that saving the full transitive object closure may at
times be too coarse grained, the Mjølner System allows the
programmer to control what part of the reachable object graph is
actually saved along. This allows pointers from persistent objects to
non-persistent objects despite the reachability based persistence
model.
The persistence frameworks have gone through a number of iterations:
-
The first ideas for persistence in Mjølner were presented in [Agesen 89]
and a first implementation of single-user persistence was made by Claus Nørgaard.
- The first product-quality implementation of single-user
persistence was made by Søren Brandt. Design considerations,
experience and recommendations for a re-design are documented in the
PhD Thesis of Søren Brandt [Brandt94]. This version of basic object management
has been part of the Mjølner System for many years and is
referred to as the old basic object management.
- A multi-user shared persistence store with concurrency control,
transaction management and notifications has recently been developed
by Johanna Wiederhold Tind [Tind97].
- Recently a new and more efficient implementation of the basic
object management has been implemented by Stephan Erbs Korsholm
[Korsholm99]. This work a.o. benefits from the work of Søren Brandt.
This version of the basic object management is referred to as
the new basic object management.
The new basic object management will eventually replace the old
basic object management. In release 5.0 of the Mjølner System the
old- as well as the new basic object management are included. We
recommed to use the new basic object management since it is much more
efficient than the old one. However, as this is the first release
of the new basic object management, there may still be some errors or
problems that have not yet been discovered.
The old and the new basic object management both work with the
shared persistent store.
The directory
contains the new basic object management as well as the shared
persistent store.
The directory
contains the old persistent store.
The interface to the old and the new persistent store is the same.
That is, it is possible to alternate between the old and the new store by
including either
~beta/persiststore/persistentstore |
or
~beta/persiststore/OLD/persistentstore |
Persistence in BETA - Reference Manual |
© 1991-2002 Mjølner Informatics |
[Modified: Monday October 23rd 2000 at 10:43]
|