In this paper, different approaches are classified and evaluated for optimizing the access to main-memory resident persistent objects---techniques which are commonly referred to as "pointer swizzling ". To speed up the access along inter-object references, the persistent pointers in the form of unique object identifiers (OIDs) are transformed (swizzled) into main-memory pointers (addresses). Pointer swizzling techniques can be directed into two classes: (1) strategies that allow replacement of swizzled objects from the buffer before the end of an application program and (2) those that outrule the displacement of swizzled objects. Whereas the latter class of pointer swizzling methods has received much attention in recent literature, the first class---i.e., techniques that take "precautions" for the replacement of swizzled objects---has not yet been thoroughly investigated. Four different pointer swizzling techniques allowing object replacement were investigated and contrasted with the p...

In this work, control strategies for combining two potentially powerful buffer management techniques in object bases were devised and evaluated: (1) buffer pool segmentation with segment-specific replacement criteria, and (2) dual buffering consisting of copying objects from pages into object buffers. Two diien-sions exist for exerting control on the buffer pool: (1) the copying time which determines at what time objects are copied from their memory-resident home page, and (2) the relo-cation time which determines when a (copied) object is to be transferred back to its home page. Along both dimensions, it is possible to differentiate between an eager and a lazy strategy. The extensive experimental results indicate that lazy object copying combined with an eager relocation strategy is almost always superior and significantly outperforms page-based buffering in most applications. 1

A distributed object database stores objects persistently at servers. Applications run on client machines, fetching objects into a client-side cache of objects. If fetching and cache management are done in terms of objects, rather than fixed-size units such as pages, three problems must be solved: 1. which objects to prefetch, 2. how to translate, or swizzle, inter-object references when they are fetched from server to client, and 3. which objects to displace from the cache. This thesis reports the results of experiments to test various solutions to these problems. The experiments use the runtime system of the Thor distributed object database and benchmarks adapted from the Wisconsin OO7 benchmark suite. The thesis establishes the following points: 1. For plausible workloads involving some amount of object fetching, the prefetching policy is likely to have more impact on performance than swizzling policy or cache management policy. 2. A simple breadth-first prefetcher can have performa...

This paper presents the architectureof BeSS -- a high performance configurable database storage manager providing key facilities for the fast development of object-oriented, relational, or home-grown database management systems. BeSS is based on a multi-client multi-server architecture offering distributed transaction management facilities and extensible support for persistence. We present some novel aspects of the BeSS architecture, including a fast object referencetechnique that allows re-organization of databases without affecting existing references and two operation modes that an application running on a client or server machine can use to interact with the storage system -- copy on access and shared memory.

Distributed persistent object systems provide a convenient environment for applications that need to manage complex long-lived data. Since Java has no persistence model built into it, the tremendous growth in the popularity of Java has generated a lot of interest in systems that add persistence to Java. This thesis presents the design, implementation and performance evaluation of a Java Persistent Store called JPS. JPS is an efficient distributed persistent Java system built on top of the Thor object-oriented database. JPS provides

If persistent programming languages are to be accepted they must provide many of the standard features of traditional database systems, including resilience in the face of system failures in which the volatile database (in-memory databasebuffers) is lost. Ensuring the consistency of the database requires the generation of recovery information sufficient to restore the database to a consistent state after a crash. This paper examines a range of schemes for the efficient generation of recovery information in persistent programming languages, and evaluates their relative performance within an implementation of Persistent Smalltalk.

Implementing crash recovery in an Object-Oriented Database System (OODBMS) raises several challenging issues for performance that are not present in traditional DBMSs. These performance concerns result both from significant architectural differences between OODBMSs and traditional database systems and differences in OODBMS’s target applications. This paper compares the performance of several alternative approaches to implementing crash recovery in an OODBMS based on a client-server architecture. The four basic recovery techniques examined in the paper are termed page differencing, sub-page differencing, whole-page logging, and redo-at-server. All of the recovery techniques were implemented in the context of QuickStore, a memory-mapped store built using the EXODUS Storage Manager, and their performance is compared using the OO7 database benchmark. The results of the performance study show that the techniques based on differencing generally provide superior performance to whole-page logging. 1.

LIGHTWEIGHT SUPPORT FOR FINE-GRAINED PERSISTENCE ON STOCK HARDWARE FEBRUARY 1995 ANTONY LLOYD HOSKING B.Sc., UNIVERSITY OF ADELAIDE M.Sc., UNIVERSITY OF WAIKATO Ph.D., UNIVERSITY OF MASSACHUSETTS AMHERST Directed by: Professor J. Eliot B. Moss Persistent programming languages combine the features of database systems and programming languages to allow the seamless manipulation of both short- and long-term data, thus relieving programmers of the burden of distinguishing between data that is transient (temporarily allocated in main memory) or persistent (residing permanently on disk). Secondary storage concerns, including the representation and management of persistent data, are directly handled by the programming language implementation, rather than the programmer. Moreover, unlike traditional database systems, persistent programming languages extend to persistent data all the data structuring features supported by the language, not just those imposed by the underlying database system. P...

: Once considered a novelty, object oriented systems have now entered the mainstream. Their impressive performance and rich type systems have created a demand for object oriented features in other areas, such as relational database systems. We believe the current efforts to combine object oriented and relational features into a single hybrid system will fall short of the mark, whereas our approach, the co-existence approach, has the distinction of requiring far less work, but at the same time promising both the desired functionality and performance. We describe the attributes of our co-existing systems, an object oriented system (C++) and a relational system (Starburst), and show how this combination supports the desired features of both object-oriented and relational systems. 1 Introduction During the last few years Object Oriented Systems (OOSs) have proven successful in managing complex data processing tasks inherent in applications such as computer aided design/manufacturing (CA...

this paper, we discuss the principles, architecture, and implementation of the Penguin approach to sharing persistent objects. The primary motivation for using a database management system (DBMS) is to allow sharing of data among multiple customers and multiple applications. To support sharing among independent transactions, DBMSs have evolved services including transaction independence, persistence, and concurrency control. When a database is shared among multiple applications, these applications typically have differing requirements for data access and representation. Such differences are supported by having views, which present diverse subsets of the base data [ChamGT75]. The primary motivation for defining objects is to include sharable semantics and structure in the information. Must all applications sharing objects use the same object schema, or is it better to give each application its own object schema and somehow to integrate them? If multiple applications differ in view the needed compromise reduces the relevance and effectiveness of the object representation [AbitB91]. For instance, customers will have an orthogonal view of an inventory versus the suppliers. 2 When combining independently developed applications, we do not have the luxury of choosing a common object schema. Many legacy databases and legacy data are still being used. We must retain the investment in existing application software and databases, while building new software using the object approach. When creating a federation of heterogeneous (pre-existing) databases, we must support a degree of interoperation among these databases and their schemas. Consider also that current projects will become legacy in a few years hence, but their semantics will remain. Whatever solutions we create in shar...