Persistent Object Store Research Articles

Working with persistent objects: to swizzle or not to swizzle

Pointer swizzling is the conversion of database objects between an external form (object identifiers) and an internal form (direct memory pointers). Swizzling is used in some object-oriented databases, persistent object stores, and persistent and database programming language implementations to speed manipulation of memory resident data. The author describes a simplifying model of application behavior, revealing those aspects where swizzling is most relevant in both benefits and costs. The model has a number of parameters, which the authors have measured for a particular instance of the Mneme persistent object store, varying the swizzling technique used. The results confirm most of the intuitive, qualitative tradeoffs, with the quantitative data showing that some performance differences between schemes are smaller than might be expected. However, there are some interesting effects that run counter to naive intuition, most of which are explained using deeper analysis of the algorithms and data structures.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Design of the Mneme persistent object store

The Mneme project is an investigation of techniques for integrating programming language and database features to provide better support for cooperative, information-intensive tasks such as computer-aided software engineering. The project strategy is to implement efficient, distributed, persistent programming languages. We report here on the Mneme persistent object store, a fundamental component of the project, discussing its design and initial prototype. Mneme storesobjectsin a simple and general format, preserving object identity and object interrelationships. Specific goals for the store include portability, extensibility (especially with respect to object management policies), and performance. The model of memory that the store aims at is a single, cooperatively-shared heap, distributed across a collection of networked computers. The initial prototype is intended mainly to explore performance issues and to support object-oriented persistent programming languages. We include performance measurements from the prototype as well as more qualitative results.

Architecture of the ORION next-generation database system

Various architectural components of ORION-1 and ORION-1SX are described and a review of the current implementation is provided. The message handler receives all messages sent to the ORION system. The object subsystem provides high-level data management functions, including query optimization, schema management, long data management (including text search) and support for versionable objects, composite objects, and multimedia objects. The transaction management subsystem coordinates concurrent object accesses and provides recovery capabilities. The storage subsystem manages persistent storage of objects and controls the flow of objects between the secondary storage device and main memory buffers. In ORION-1, all subsystems reside in one computer. The ORION-1SX architecture is significantly different from ORION-1 in the management of shared data structures and distribution of these subsystems and their components.< <ETX xmlns:mml="http://www.w3.org/1998/Math/MathML" xmlns:xlink="http://www.w3.org/1999/xlink">&gt;</ETX>

Layered implementations of persistent object stores

In the paper, the potential of persistent object stores as a replacement for filestores is identified. One of the obstacles to this happening is the lack of standardised object representations. The problems of standardisation are discussed and a 7-layer model proposed. A case is made out for using universal persistent identifiers to refer to persistent objects.

OBJEKT—a persistent object store with an integrated garbage collector

This paper describes OBJEKT, a single-level persistent storage system designed for the REKURSIV architecture.It will be shown that OBJEKT can be microcoded to implement "objects" efficiently, and that data integrity can be guaranteed by provision of an object oriented instruction set. Particular attention will be paid to its facilities for type and range checking, to its object by- object paging strategy and to ways of enhancing parallelism during garbage collection.