Results 1 - 10
of
17
The OO7 benchmark
, 1993
"... The OO7 Benchmark represents a comprehensive test of OODBMS performance. In this report we describe the benchmark and present performance results from its implementation in four OODB systems. It is our hope that the OO7 Benchmark will provide useful insight for end-users evaluating the performance o ..."
Abstract
-
Cited by 258 (11 self)
- Add to MetaCart
The OO7 Benchmark represents a comprehensive test of OODBMS performance. In this report we describe the benchmark and present performance results from its implementation in four OODB systems. It is our hope that the OO7 Benchmark will provide useful insight for end-users evaluating the performance of OODB systems; we also hope that the research community will nd that OO7 provides a database schema, instance, and workload that is useful for evaluating new techniques and algorithms for OODBMS implementation.
The Design of the E Programming Language
- ACM Transactions on Programming Languages and Systems
, 1993
"... E is an extension of C++ designed for writing software systems to support persistent applications. Originally designed as a language for implementing database systems, E has evolved into a general persistent programming language E was the first C++ extension to support transparent persistence, the f ..."
Abstract
-
Cited by 57 (3 self)
- Add to MetaCart
E is an extension of C++ designed for writing software systems to support persistent applications. Originally designed as a language for implementing database systems, E has evolved into a general persistent programming language E was the first C++ extension to support transparent persistence, the first C++ implementation to support generic classes, and remains the only C++ extension to provide general-purpose lterators, In addition to its contributions to the C + + programming domain, work on E has made several contributions to the field of persmtent languages in general, including several distinct implementations of persistence. Thm paper describes the main features of E and shows through examples how E addresses many of the problems that arise in building persistent systems.
TIGUKAT: A Uniform Behavioral Objectbase Management System
- THE VLDB JOURNAL
, 1995
"... We describe the TIGUKAT objectbase management system that is under development at the Laboratory for Database Systems Research at the University of Alberta. TIGUKAT has a novel object model whose identifying characteristics include a purely behavioral semantics and a uniform approach to objects. Eve ..."
Abstract
-
Cited by 39 (15 self)
- Add to MetaCart
We describe the TIGUKAT objectbase management system that is under development at the Laboratory for Database Systems Research at the University of Alberta. TIGUKAT has a novel object model whose identifying characteristics include a purely behavioral semantics and a uniform approach to objects. Everything in the system, including types, classes, collections, behaviors, functions as well as meta-information, is a first-class object with well-defined behavior. In this way, the model abstracts everything, including traditional structural notions such as instance variables, method implementation and schema definition, into a uniform semantics of behaviors on objects. Our emphasis in this paper is on the object model, its implementation, the persistence model and the query language. We also (briefly) present other database management functions that are under development such as the query optimizer, the version control system and transaction manager.
Crash Recovery in Client-Server EXODUS
- In Proceedings of ACM-SIGMOD 1992 International Conference on Management of Data
, 1992
"... In this paper, we address the correctness and performance issues that arise when implementing logging and crash recovery in a page-server environment. The issues result from two characteristics of page-server systems: 1) the fact that data is modified and cached in client database buffers that are n ..."
Abstract
-
Cited by 28 (6 self)
- Add to MetaCart
In this paper, we address the correctness and performance issues that arise when implementing logging and crash recovery in a page-server environment. The issues result from two characteristics of page-server systems: 1) the fact that data is modified and cached in client database buffers that are not accessible by the server, and 2) the performance and cost tradeoffs that are inherent in a client-server environment. We describe a recovery system that we have implemented for a particular page-server system: the client-server version of the EXODUS storage manager. The implementation supports efficient buffer management policies, allows flexibility in the interaction between clients and the server, and reduces the load on the server by performing much of the work involved in generating log records at clients. We also present a preliminary performance analysis of the implementation, examining the relative costs of logging and recovery operations and identifying areas for future improvement. 1.
Structuring Fault-Tolerant Object Systems for Modularity in a Distributed Environment
"... The object-oriented approach to system structuring has found widespread acceptance among designers and developers of robust computing systems. In this paper we propose a system structure for distributed programming systems that support persistent objects and describe how such properties as persisten ..."
Abstract
-
Cited by 22 (10 self)
- Add to MetaCart
The object-oriented approach to system structuring has found widespread acceptance among designers and developers of robust computing systems. In this paper we propose a system structure for distributed programming systems that support persistent objects and describe how such properties as persistence, recoverability etc. can be implemented. The proposed structure is modular, permitting easy exploitation of any distributed computing facilities provided by the underlying system. An existing system constructed according to the principles espoused here is examined to illustrate the practical utility of the proposed approach to system structuring.
Persistence in E Revisited --- Implementation Experiences
- In Dearle et al. [DSZ90
, 1990
"... This paper discusses the design and implementation of the E Persistent Virtual Machine (EPVM), an interpreter that provides support for persistent data access in the current version of the E programming language. Included are descriptions of both the EPVM interface and the major implementation tacti ..."
Abstract
-
Cited by 10 (2 self)
- Add to MetaCart
This paper discusses the design and implementation of the E Persistent Virtual Machine (EPVM), an interpreter that provides support for persistent data access in the current version of the E programming language. Included are descriptions of both the EPVM interface and the major implementation tactics employed within EPVM. A novel pointer swizzling scheme that has been investigated in the context of E and EPVM is also described. Finally, a performance analysis of the key EPVM primitives is presented. 1. INTRODUCTION This paper discusses the current implementation of access to persistent data in the E programming language. E is a persistent, object-oriented programming language that was developed as an extension of C++ [Stro86] for use in the EXODUS project at the University of Wisconsin [Care89a]. The E language was originally designed for use in constructing database management system software; an overview of the design and motivation for E can be found in [Rich89a]. Basically, three...
Residency Check Elimination for Object-Oriented Persistent Languages
- In Connor and Nettles [27
, 1997
"... We explore the ramifications of object residency assumptions and their impact on residency checking for several subroutine dispatch scenarios: procedural, static object-oriented, and dynamic (virtual) object-oriented. We obtain dynamic counts of the residency checks necessary for execution of severa ..."
Abstract
-
Cited by 5 (5 self)
- Add to MetaCart
We explore the ramifications of object residency assumptions and their impact on residency checking for several subroutine dispatch scenarios: procedural, static object-oriented, and dynamic (virtual) object-oriented. We obtain dynamic counts of the residency checks necessary for execution of several benchmark persistent programs under each of these scenarios. The results reveal that significant reductions in the number of residency checks can be achieved through application of residency rules derived from the dispatch scenario under which a program executes, as well as additional constraints specific to the language in which it is implemented. Keywords: residency checks, optimization, object-orientation, static/dynamic dispatch 1 Introduction Persistent programming languages view permanent storage as a stable extension of volatile memory, in which objects may be dynamically allocated, but which persists from one invocation to the next. A persistent programming language and object st...
Rationale and Design of BULK
, 1991
"... BULK is a very-high-level persistent programming language and environment for prototyping and implementing database applications. BULK provides sets and sequences as primitive type constructors, provides high-level operations on them, and allows programmers to define application-oriented bulk types, ..."
Abstract
-
Cited by 5 (2 self)
- Add to MetaCart
BULK is a very-high-level persistent programming language and environment for prototyping and implementing database applications. BULK provides sets and sequences as primitive type constructors, provides high-level operations on them, and allows programmers to define application-oriented bulk types, e.g. syntax trees, bond portfolios, or (geographic) maps. BULK encourages separation of correctness and efficiency concerns by distinguishing logical type from representation. BULK supports a three-step development paradigm consisting of (i) prototyping, (ii) intensive analysis, optimization, and data structure selection by the compiler to achieve efficiency, and (iii) if efficiency is still inadequate, hot-spot refinement [CGK89]. (In hot-spot refinement developers remove performance bottlenecks by providing the compiler with more information, by directing its optimization efforts, or by re-implementation.) Step (i) focuses on correctness, steps (ii) and (iii) on efficiency. Our goal is an implementation that can usually achieve acceptable efficiency by step (ii) and that provides a tractable interface for hot-spot refinement.
Mostly-Copying Reachability-Based Orthogonal Persistence
- In OOPSLA '97 Workshop on Memory Management and Garbage Collection
, 1999
"... We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula-3, and without modification to the compiler. Our scheme extends Bartlett's mostly-copying garbage collector to manage both transient objects and reside ..."
Abstract
-
Cited by 4 (1 self)
- Add to MetaCart
We describe how reachability-based orthogonal persistence can be supported even in uncooperative implementations of languages such as C++ and Modula-3, and without modification to the compiler. Our scheme extends Bartlett's mostly-copying garbage collector to manage both transient objects and resident persistent objects, and to compute the reachability closure necessary for stabilization of the persistent heap. It has been implemented in our prototype of reachability-based persistence for Modula-3, yielding performance competitive with that of comparable, but non-orthogonal, persistent variants of C++. Experimental results, using the OO7 object database benchmarks, reveal that the mostly-copying approach offers a straightforward path to efficient orthogonal persistence in these uncooperative environments. The results also characterize the performance of persistence implementations based on virtual memory protection primitives. 1 Introduction Incorporating orthogonal persistence [11] ...
Interoperability Between Object-Oriented Programming Languages and Relational Systems
- In Proceedings of TOOLS Conference
, 1995
"... With a growing acceptance of object technology, it becomes important for objectoriented programming environments to support accessing and manipulating relational databases. The work described in this paper aims to improve the interoperability between object-oriented systems and relational systems. W ..."
Abstract
-
Cited by 3 (1 self)
- Add to MetaCart
With a growing acceptance of object technology, it becomes important for objectoriented programming environments to support accessing and manipulating relational databases. The work described in this paper aims to improve the interoperability between object-oriented systems and relational systems. We call the ability of two or more systems, usually written in different languages, to communicate to each other or to work together the interoperability between the systems. In this paper, we first discuss possible methods for achieving the interoperability between object-oriented and relational systems and existing work related to this goal. We then describe our approach for building an object-oriented persistent programming environment to support accessing and manipulating relational databases. 1 Introduction With a growing acceptance of object technology, object-oriented programming languages (OOPLs) are being used in the development of many new systems. On the other hand, there is also ...

