Persistent Programming Language Research Articles

A virtual type for a multiple‐type object and its implementation

AbstractTo deal with the evolution of data and applications and with the existence of multiple views for the same data, the object data model needs to be extended with the object extension functionality to allow an object to dynamically change its type, and the object viewing functionality to allow an object to be seen as if it had a different structure and behavior. This paper proposes the virtual type facility which provides a persistent object of ?, an enhanced C++ persistent programming language compliant with the ?standard, with a different structure and behavior from those of its base types. Additionally, it presents the implementation details of the facility. The virtual type facility gives a different interface of an object to redefine its structure and behavior without affecting the behavior of a base type, while the multiple‐type object of ?allows an object to be dynamically extended to model an entity which changes its behavior with time. The virtual type facility integrates the object extension functionality and the object viewing functionality for dealing with the database evolution. © 2007 Wiley Periodicals, Inc. Syst Comp Jpn, 38(11): 25–35, 2007; Published online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/scj.20781

Implementation of automated fine-granularity locking in a persistent programming language

To gain broader acceptance, Persistent Programming Languages (PPL) need a better integration of the transaction paradigm. Much like database systems, computations should all run in the context of a transaction; the transactional properties should be applied to all objects irrespective of their type and lifetime, and they must be enforced automatically via safe and efficient mechanisms. This requires lock managers that can cope with the requirement for automated locking in a PPL. This paper reports our design and implementation of such lock managers and the accompanying machinery that a PPL must incorporate to automate locking. Our innovative ingredients for an efficient lock management recipe are a close collaboration with the memory manager of the PPL and the sharing of lock data structures of equal value between locked objects. Sharing such lock values has numerous benefits: it makes the space consumption of locking negligible and independent of the number of locks, which frees transactions of any restriction on the volume of locks that they can use; it eliminates the need for expensive book-keeping of locks by transactions; and it enables the use of both non-blocking synchronization and memorization techniques for whole locking operations. These features combine to achieve fast lock acquisition for the non-blocking cases (6 RISC instructions), and make releasing locks practically free. The impact of lock management techniques and automated locking strategy on the performance of a PPL are analysed based on measurements of various lock managers integrated into PJama, a JavaTM Virtual Machine (JVM) which provides orthogonal persistence. Copyright © 2000 John Wiley & Sons, Ltd.

Multiple‐type objects in an enhanced C++ persistent programming language

An entity in the real world may obtain and lose its roles, or aspects, again and again with time. For modeling such dynamic changes of aspects, objects having multiple types, or multiple-type objects, are essential to persistent programming languages. In this paper, we introduce multiple-type objects, and show a method of implementing them in an enhanced C++ persistent programming language called INADA. Any persistent objects in INADA may obtain any type at any time the type is needed, and may lose any unnecessary types dynamically. We also present a performance study in which the performance penalty caused by the introduction of multiple-type objects was examined. Copyright © 2000 John Wiley & Sons, Ltd.

Multiple-type objects in an enhanced C++ persistent programming language

Multiple-type objects in an enhanced C++ persistent programming language

Alightweight class library for extended persistent object management in C++

When applications must keep their data structures persistent, additional effort beyond transient modeling is necessary to realize suitable persistent storage. The most convenient approach is the use of a persistent programming language (PPL), which offers internal mechanisms for storing and loading data transparently for the application programmer. An alternative to a PPL is a universal programming language that has been extended by persistence concepts for any data types

Exploiting Persistence in Build Management

A challenging issue in the construction and maintenance of large application systems is how to determine which components need to be rebuilt after change, when and in which order. Rebuilding is typically recompilation and linking, but may also include update of derivable components such as cross-reference databases and re-creation of library indexes. Type definitions or schema, and data values in a file store, database or persistent store may also need to be rebuilt. The main purpose of this paper is to describe how persistent language technology can be exploited to enhance build management. In particular, the paper describes a method for transactional, incremental linking and the implementation of its support. To help implement this method, and to make it safer and more efficient to carry out rebuild activities in general, we have defined a set of automatically checkable constraints on the software. The build management tool we have implemented, the Builder, derives rebuild dependencies automatically and offers partitioning of dependency graphs—a means to defer or avoid unnecessary rebuilding. The Builder is implemented in a persistent programming language and provides build management for applications written in the language. It exploits features such as strong typing, runtime linguistic reflection, and referential integrity provided by the language processing technology. The Builder operates over both programs and (complex) data, which is in contrast to conventional language-centred tools. © 1997 by John Wiley & Sons, Ltd.

Exploiting Persistence in Build Management

A challenging issue in the construction and maintenance of large application systems is how to determine which components need to be rebuilt after change, when and in which order. Rebuilding is typically recompilation and linking, but may also include update of derivable components such as cross-reference databases and re-creation of library indexes. Type definitions or schema, and data values in a file store, database or persistent store may also need to be rebuilt. The main purpose of this paper is to describe how persistent language technology can be exploited to enhance build management. In particular, the paper describes a method for transactional, incremental linking and the implementation of its support. To help implement this method, and to make it safer and more efficient to carry out rebuild activities in general, we have defined a set of automatically checkable constraints on the software. The build management tool we have implemented, the Builder, derives rebuild dependencies automatically and offers partitioning of dependency graphs—a means to defer or avoid unnecessary rebuilding. The Builder is implemented in a persistent programming language and provides build management for applications written in the language. It exploits features such as strong typing, runtime linguistic reflection, and referential integrity provided by the language processing technology. The Builder operates over both programs and (complex) data, which is in contrast to conventional language-centred tools. © 1997 by John Wiley & Sons, Ltd.

The persistent workshop - a programming environment for Napier88

The Persistent Workshop is a programming environment to support the construction of application systems in Napier88, a persistent programming language. In addition to supporting programming activit...

Object persistence in object-oriented applications

Object-oriented models have rapidly become the model of choice for programming most new computer applications. Since most application programs need to deal with persistent data, adding persistence to objects is essential to making object-oriented applications useful in practice. There are three classes of solutions for implementing persistence in object-oriented applications: the gateway-based object persistence approach, which involves adding object-oriented programming access to persistent data stored using traditional non-object-oriented data stores, the object-relational database management system (DBMS) approach, which involves enhancing the extremely popular relational data model by adding object-oriented modeling features, and the object-oriented DBMS approach (also called the persistent programming language approach), which involves adding persistence support to objects in an object-oriented programming language. In this paper, we describe the major characteristics and requirements of object-oriented applications and how they may affect the choice of a system and method for making objects persistent in that application. We discuss the user and programming interfaces provided by various products and tools for object-oriented applications that create and manipulate persistent objects. In addition, we describe the pros and cons of choosing a particular mechanism for making objects persistent, including implementation requirements and limitations imposed by each of the three approaches to object persistence previously mentioned. Given that several object-oriented applications might need to share the same data, we describe how such applications can interoperate with each other. Finally, we describe the problems and solutions of how object-oriented applications can coexist with non-object-oriented (legacy) applications that access the same data.

Experiences in database system implementation using a persistent programming language

AbstractThe EXODUS database toolkit, and in particular the E persistent programming language, have been used in two substantial database system implementation efforts by the authors, the Ariel database rule system and the Triton nested relation DBMS. An important advantage of using a persistent programming language for database system implementation is that it is easy to implement special‐purpose persistent objects used by the DBMS such as catalogs, rule indexes, and nested relational structures. Support for transactions built into a persistent programming language greatly reduces the effort required to implement a database system. A disadvantage observed is that it is not possible to map the type system of the DBMS to the type system of the underlying programming language while still retaining good performance for ad hoc queries. Also, software engineering difficulties arise when a persistent language makes a distinction between database types and main‐memory types.

Object fault handling for persistent programming languages

article Object fault handling for persistent programming languages: a performance evaluation Share on Authors: Antony L. Hosking View Profile , J. Eliot B. Moss View Profile Authors Info & Claims ACM SIGPLAN NoticesVolume 28Issue 10Oct. 1, 1993 pp 288–303https://doi.org/10.1145/167962.165907Published:01 October 1993 25citation332DownloadsMetricsTotal Citations25Total Downloads332Last 12 Months5Last 6 weeks1 Get Citation AlertsNew Citation Alert added!This alert has been successfully added and will be sent to:You will be notified whenever a record that you have chosen has been cited.To manage your alert preferences, click on the button below.Manage my AlertsNew Citation Alert!Please log in to your account Save to BinderSave to BinderCreate a New BinderNameCancelCreateExport CitationPublisher SiteGet Access

The design of the E programming language

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 iterators. In addition to its contributions to the C++ programming domain, work on E has made several contributions to the field of persistent languages in general, including several distinct implementations of persistence. This paper describes the main features of E and shows through examples how E addresses many of the problems that arise in building persistent systems

Programming versus databases in the object-oriented paradigm

The object-oriented paradigm has come to the forefront of the research community in the software engineering, programming language, and database research areas. Moreover, the paradigm appears capable of supporting advanced applications such as software development environments (SDEs) that require both programming ability and persistency via a database system. However, there exists a disparity between the programming and database approaches to the object-oriented paradigm. The paper examines and discusses this disparity between the two approaches for the purpose of formulating an understanding of their commonalities and differences. This understanding has been instrumental in supporting work involving the prototyping of SDEs using the object-oriented paradigm, an examination of the techniques required to evolve a class library for persistency, and the proposal of a software architecture and functionality of a persistent programming language system. Thus, it is believed that the work presented in this paper can serve as a framework for researchers and practitioners whose efforts include the aforementioned or other, related areas. From a content perspective, this paper provides a comparative analysis between the concepts of programming and databases for the object-oriented paradigm, through a detailed presentation of system-level and model-level considerations. Both philosophical concepts and implementation pragmatics are investigated. A practical examination of the C++ programming language versus the Opal data language has been conducted, revealing many valuable insights of systems and application details and issues. Features of both approaches are also analysed and illustrated.

Using persistence to support incremental system construction

This paper describes the use of a persistent store to support incremental system construction. A single example is elaborated throughout the paper to introduce elements of the incremental construction mechanism. The essence of the technique is to permit assignment of executable program fragments to typed locations in order to change the behaviour of a program under construction. The technique described relies upon the existence of three features: a persistent store, updatable locations and first class executable values. The examples given use the persistent programming language Napier88, but any language with these features could be used to construct such a system.

Programming persistence in chi

The ways in which a persistent programming language allows the reuse of data and code objects by preserving them as persistent objects is discussed. The programming language chi , which supports persistent programming, is described. The language is innovative in that it elevates capabilities to the programming level and gives the programmer a convenient way to express which objects are persistent independently of the type of object. Thus, it provides orthogonal persistence. A further advantage that follows from such use of capabilities is that chi provides an implementation path for persistence, even upon architectures that do not support capabilities directly. >

Semantic integrity for persistent objects

Modelling constructs for specifying semantic integrity are reviewed, and their implicit execution semantics are discussed. An integrity maintenance model based on these constructs is presented. An implementation of this model in a persistent programming language is described, allowing flexible automated dynamic integrity management for applications that update a persistent store; this implementation is based on an event-driven architecture.

Experiences in DBMS implementation using an object-oriented persistent programming language and a database toolkit

Experiences in DBMS implementation using an object-oriented persistent programming language and a database toolkit

The design of the Triton nested relational database system

Unique database requirements of applications such as computer-aided design (CAD), computer-aided software engineering(CASE), and office information systems(OIC) have driven the development of new data models and database systems based on these new models. In particular, the goal of these new database systems is to exploit the advantages of complex data models that are more efficient (in terms of time and space) than their relational counterparts. In this paper, we describe the design and implementation of the Triton nested relational database system, a prototype system based on the nested relational data model. Triton is intended to be used as the backend storage and access component of the aforementioned applications. This paper describes the architecture of the Triton system, and compares the performance of the nested relational model versus the relational model using Triton. In addition, this paper evaluates the EXODUS extensible database toolkit used in the development of the Triton system including key features of the persistent programming language E and the EXODUS storage manager.

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.

Storage management for persistent complex objects

The emerging generation of database systems and persistent programming languages presents a new set of requirements for object management systems. In this paper, we first describe these requirements and provide a survey of prior efforts to address these issues. We then present an object model with the descriptive power to satisfy these requirements. Finally, we propose a modular architecture for an object manager which will provide efficient support for the storage, retrieval and modification of persistent complex objects. The object manager hides the internal structural details of objects from its clients. It provides direct support for indexing and does not impose any size restrictions on objects.