Chapter 2.2.4 Towards a Unified Model of Untyped Object Stores: Experience with the Tycoon Store Protocol

Florian Matthes, Rainer Müller, and Joachim W. Schmidt

Technical University Hamburg-Harburg Harburger Schloßstraße 20 D-21071 Hamburg, Germany

Summary This text is a synopsis of [2].

1. Introduction

Systems that have to work with large-scale persistent data have a system architecture where there is a clean separation between a frontend performing data manipulation and visualization and a back end responsible for reliable persistent bulk data storage. Since actions in the frontend trigger data access operations performed by the backend, this separation leads to a client-server architecture, where a store protocol defines possible interactions between a client program and a database server.

The Tycoon Store Protocol (TSP) specifies a clean interface between the frontend and the backend of fully integrated persistent environments. TSP is designed to match the flexibility requirements of persistent languages (see [1, 3] for a more detailed discussion):

– Full persistence abstraction requires uniform, efficient element-oriented access to persistent and non-persistent data, code and threads.

– Orthogonal persistence for polymorphic data structures, higher-order (polymorphic) functions and user-defined abstract data types require an untyped persistent heap.

– Incremental program construction and reflective programming techniques require schema modifications at runtime and dynamic binding techniques.

Despite the fact that TSP has been implemented and evaluated in the context of the Tycoon project (see Chapter 2.1.4), TSP is fully independent of the Tycoon system.

2. On the Construction of Scalable Persistent Systems

TSP has been designed to support the construction of scalable persistent systems, i.e., configurable systems where the complexity and size of the entire system is proportional to the operational support required by a particular client.

Figure 2.1 explains the role of TSP in such a persistent system scenario. The data access operations defined in TSP are issued by client programs and executed by database servers. In the full paper we report on our experience in implementing TSP backends including adaptors to existing object stores, e.g. ObjectStore.

F. Matthes, R. Müller, J.W. Schmidt

Fig. 2.1. The role of the Tycoon Store Protocol in scalable persistent systems

TSP defines a stable application programming interface for client programs (expressed by a standard C header file). TSP is intended to be a stackable protocol. These optional system layers utilize TSP as their lower and upper interfaces and extend the semantics of individual TSP operations (e.g., store object update) and provide additional TSP operations (e.g., rollback to savepoint). In the full paper we report on extending the TSP functionality systematically by TSP-compliant layers for persistent savepoints and access control.

TSP is complemented by a platform-independent external data representation (TXR) that can be generated and parsed by all TSP backends. The TXR makes it possible to transfer arbitrary complex, graph-structured persistent store objects via a linear data representation from one backend to another without exposing private implementation details of individual persistent stores.

A TSP client can choose dynamically between different backends and can access multiple stores (possibly of multiple architectures) concurrently. A multi-user database server like ObjectStore supports multiple TSP clients at a time which may run on different client nodes in a local area network accessing a shared persistent store.

3. An Untyped Store Model

A primary design goal behind TSP has been to provide efficient data storage as independent as possible from the data and language model supported by TSP store clients. In particular, TSP should be capable of supporting polymorphically typed models where the components of store objects can contain values of multiple types that cannot be fixed in a separate schema definition phase. TSP therefore uses an untyped low-level store model, i.e., there is no separate dictionary of type or schema information maintained by the backend. Instead of this, store values are made selfdescriptive by imposing a regular object layout and a uniform tagging scheme. As a result, TSP achieves data model independence without sacrificing the advantages

Tycoon Store Protocol

of self-descriptive statically-typed databases. In the full paper the store model is described in detail.

4. Overview of the Tycoon Store Protocol

Due to the simplicity of TSP’s data model, it is possible to define concisely all its operations. The following clusters of operations are described in the full paper:

– operations on persistent stores,

– failure handling and recovery,

– operations on store objects,

– main memory mapping of store objects,

– management of object identifiers, and

– lineraziation of store subgraphs.

5. Concluding Remarks

The main contribution of this paper is the in-depth description of an object store protocol that we regard as an excellent starting point for a standardized interface between the frontend and the backend of fully integrated persistent environments. In developing the TSP specification, its implementations and its adaptors to commercial object stores available to other research groups, we hope to establish TSP as a widely accepted protocol within persistent language implementations. This would not only simplify the development of new persistent languages but also facilitate system measurements, comparative performance studies and interoperability experiments between multiple persistent languages.

References

1. F. Matthes, R. Müller, and J.W. Schmidt. Object stores as servers in persistent programming environments – the P-Quest experience. FIDE Technical Report Series FIDE/92/48, FIDE Project Coordinator, Department of Computing Sciences, University of Glasgow, Glasgow G128QQ, July 1992.

2. F. Matthes, R. Müller, and J.W. Schmidt. Towards a unified model of untyped object stores: Experience with the Tycoon store protocol. In Advances in Databases and Information Systems (ADBIS’96), Proceedings of the Third International Workshop of the Moscow ACM SIGMOD Chapter, 1996.

3. R. Müller. Language processors and object stores: Interface design and implementation. Master’s thesis, Fachbereich Informatik, Johann Wolfgang Goethe-Universität, Frankfurt, Germany, November 1991. (In German).