In this paper, three techniques to implement logical OIDs are thoroughly evaluated: hashing, B-trees and a technique called direct mapping. Among these three techniques, direct mapping is the most robust; it induces at most one page fault to map an OID, and it scales very well to large, rapidly growing databases. Furthermore, the clustering of handles that are used to map logical OIDs is studied. In particular, the performance of B-trees and direct mapping can improve significantly if the handles of objects that are frequently accessed by the same methods are clustered. For direct mapping, two placement policies are compared: linear and matrix clustering. 1 Introduction The full support of object identity is one of the most important features of object-oriented database systems [KM94]. To improve referential integrity, an object base system allocates an object identifier (OID) to every object at the time the object is created. The OID is used to identify the object uniquely and to im...

Heterogeneity in persistent object systems gives rise to a range of interoperability problems. For instance, a given object-oriented database (OODB) may contain data objects originally defined, created and persistently stored using the capabilities provided by several distinct programming languages, and an application may need to uniformly process those data objects. We call such a database polylingual and term the corresponding interoperability problem the polylingual access problem. While many of today's OODBs support multiple programming language interfaces (we term such systems multilingual), none provide transparent polylingual access to persistent data. Instead, present day interoperability mechanisms generally rely on external data definition languages (such as ODMG's ODL), thus reintroducing impedance mismatch and forcing developers to anticipate heterogeneity in their applications, or depend upon direct use of such low-level constructs as the foreign language interf...

In a previous paper [9] we described our goals and plans for an approach to seamlessly integrating persistence, interoperability and naming capabilities with Java. Having now completed a prototype implementation of our JSPIN approach, we have begun the process of assessing it, and some other alternative approaches, from a variety of perspectives. In particular, we have begun to measure performance by adapting a standard benchmark for use with our prototype and some representative alternatives. We have also started to make some qualitative assessments of our approach and some of its competitors based on several usability factors, particularly those that were among the goals enunciated in our previous paper. In this paper we outline our JSPIN approach and its implementation, describe the performance benchmark and present initial data resulting from its application, discuss our preliminary observations concerning usability factors, and sketch our plans for further development, as...

The SPIN #Support for Persistence# Interoperability and Naming# framework was developed as a unifying conceptual foundation for integrating extended features in software systems. SPIN has previously been used as a basis for seamlessly integrating persistence# interoperability and naming capabilities in extended versions of the C## and CLOS APIs of the TI#Arpa Open Object#Oriented Database #Open OODB#. We are currently developing JavaSPIN# a seamless integration of persistence# interoperabil# ity and naming with Java. The foundations for JavaSPIN are the SPIN framework# the Open OODB kernel and Java itself. To minimize barriers to adoption# JavaSPIN will impose no modi#cations on the Java language or the Java Virtual Machine. To max# imize opportunities for interoperability# JavaSPIN will have a persistence model and language#independent name management mechanism in common with the Persistent C## and Persistent CLOS APIs of Open OODB. In this paper we discuss our goals for J...

Name management is among the most basic foundations of software engineering, since so many software engineering tools and techniques fundamentally depend upon manipulation of names and the entities that they represent. While many individual tools and techniques have included their own specialized, often elaborate and idiosyncratic, approaches to name management, no unifying models for name management currently exist. As a result, the individual approaches are frequently complex and error-prone, while attempts to integrate collections of software engineering tools or techniques are often impeded by the inconsistency and incompatibility of the name management approaches used in the individual components of the collection. In this paper we consider some examples in which name management problems complicate software engineering activities. In particular, we focus on context control-related problems that often occur during software development. We then outline a unifying model of name manag...

The appeal of persistent class-oriented programming languages is great. Allowing class definitions to be persistent, in addition to instance data, greatly increases the ease of achieving and maintaining consistency among type definitions and their instances. Persistent class definitions become a serious impediment if they cannot evolve, however, as software systems are constantly evolving. In previous work we demonstrated Jspin, an orthogonal persistence extension for Java that does not require a modified Java Virtual Machine. In this paper we discuss our progress towards extending Jspin to allow persistent class definitions and evolution of persistent classes. We believe that we have succeeded in doing this in a way that still allows operation in an applet environment. 1 Introduction The appeal of persistent class-oriented programming languages (such as Java) is great. As part of our ongoing research program we have been developing a persistence extension for Java, which we call Jspi...