Persistent Object Systems

Rob Kremer, University of Calgary

This paper surveys the wide range of possible persistent object systems, from relatively simple object I/O to sophisticated OODBMS systems. The fundamental requirements of persistent object systems include rich persistent data models, seamlessness, and reasonably high performance. However, more sophisticated systems will support evolution of instances and classes, object sharing, distributed objects, platform independent objects, concurrency control, flexible transactions, and access control. Persistent systems can be classified over several dimensions such as object model used, navigation vs queries, storage type, transaction support, etc. A detailed look at the simplest persistence implementation (object I/O) is presented, along with suggestions on how this simple framework could be extended to support some of the more advanced features.

Introduction

The objective of this paper is to present an overview of persistent object systems. Some of the persistence requirements for application programmers are enumerated in section 2. A rough taxonomy of persistent systems is presented in section 3. Finally, a detailed view of simple object I/O systems, the lowest level of persistent systems, is given in section 4. Borland's object I/O class library is presented as a concrete example in this last section.

In this paper, the word "persistence" will be taken to mean the very general concept of objects somehow living between invocations of a program or programs. This is taken to mean somewhat more than simple file I/O but not much more. Therefore, "persistent systems" covers anything from simple object I/O systems, to the most complex and extended OODBs. The term "OODB" and "OODBMS" will be taken to mean a persistent system with at least some form of independent storage management (with the object I/O systems don't have).

It is not within the scope of this paper to discuss the object-oriented paradigm in detail, so I will assume the reader has his own opinion about what "object oriented" means. However, a short discussion defining a few base terms and how they apply to persistence is in order.

Classes, Types and Shapes

These distinctions are important to persistent systems. For example, a persistent system might be able to allow both a new version of class definition, as well as the original version (two different classes), to operate on the same objects in persistent store, if both classes are of the same type and shape.

Object Identity

Software Engineering Requirements

Fundamental Requirements

Rich Data Modeling

Seamlessness

Performance

Other Requirements

Support for Evolving Instances and Classes

Sharing of Objects among Applications

Distributed Objects

Platform Independent Objects

Concurrency Control

Flexible Transactions

Security

Persistent System Taxonomy

Object Model

Integration of Programming Language and Database

Value Oriented vs OODBs

On the other hand, true object-oriented databases reject the more conventional data models in favour of a true object model. (Although critics note that the object model isn't a lot different from the earliest databases using the hierarchical and network models.) While the object model is more to the point, value-oriented extensions have the advantage of a good deal of technology behind them, and the possibility of smooth migration from current systems.

Classes and Types

Object Identity

A alternate approach is to use the entity relationship model, where all inter-object references are outside the scope of the object and are separate objects in their own right. This method is slower because references are not directly accessible from inside an object.

Another approach is to go with the relational database approach and force all references to be queries. This does not necessarily rule out object identity because artificial "uniqueness" fields can be created. This approach can be very clean in systems that support efficient queries since there is only one access method, but the expense of calling the query processor for every single reference could be prohibitive.

Side-by-side name spaces is another approach that is (more or less) intermediate to queries and OIDs. These implementations support separate names spaces for transient and persistent objects. Ada PGraphite and C++ Persi [Wolf 90] use the persistent name space to bring objects into working memory, where the transient name space is used. EC++ [Sequeira 91] and Arjuna [Dixon 89] use the persistent name space for all persistent references.

Active vs Passive Objects

Navigation vs Queries

Persistent language based OODBs (Navigation)

An example of an extension language is E [Schuh 90], an extension of C++ which introduces an new storage class persistent, and new db primitive types. [Atwood 90] is a comparison of a persistent C++ extension (OQL) and a C++ class library implementation. OQL is also interesting in that it is a C++ language extension that also supports queries.

Query-language OODBs

Indexing

Class Hierarchy

In class (is-a) hierarchy indexing, classes are viewed as sets, just as a domain is a set in the relational database model. A query is a search through all objects (members) in a particular class (set). There arises here a problem: in light of inheritance, what are we to define as members of a class? If class D inherits from class B, then is object d (an instance of D) also a "member" of class B, since it "is-a" B and contains all data members and methods of B? An OODB that considers only direct instances of the target class is said to have single-class indexing; an OODB that considers all instances (direct or instances of all derived classes) is said to have class-hierarchy indexing [Kim 90]. OODBs that support queries must support one of these indexing capabilities.

Nested Attribute

Storage

Typeless Page Servers

Typeless Object Servers

Class-based Object Servers

Type-based Object Servers

Clustering and prefetching

Transactions

Nested Transactions

Type Specific Transactions

Long and Cooperative Transactions

Queries

Predicates

Response Sets

Semantics

Change Management

Access Control

Remote Databases

Interlanguage Sharing

User Interfaces

Implementation

Low-end (class library based) Persistence

It is my contention that, for practical purposes, a developer using OO technology today should endeavor to aim at low-end, class library-based persistence models. See [Atwood 90] for the opposite opinion, [Wolf 90] for a supporting opinion. The lowest persistent model is little more than object I/O. Object I/O involves persistent objects belonging (by inheritance) to a persistent class which contains constructors, destructors, and methods which handle the object I/O in a reasonably transparent manner. This does not mean that all objects inheriting from a persistent class are necessarily persistent, but all such objects have the potential to be persistent. It is generally accepted that persistence should be orthogonal to type [Wolf 90].

This may sound very conservative, but I believe that the OO paradigm makes even simple object I/O a very powerful tool, since objects can be made to "instantiate themselves".

Why aim so low?

Lack of standards

High cost of DB approach

Programming "in the small"

Language version problems

Object I/O

In the following discussion, I will use C++ terminology, since the case example (to follow) will use C++.

Object I/O is not quite as simple as the preceding paragraph makes it sound. In these implantations, a PERSISTENT base class contains virtual functions for object input and output to a file. Each persistent class must inherit from PERSISTENT and override the input (reader) and output (writer) functions. The writer function is responsible for writing each data member to a file. The reader function is responsible for exactly the reverse, reading in the object from a file (in exactly the same order).

Writer function

If both objects A and C are stored, the B object would be copied into the file twice. Now, when the objects are read back A and C would each reference separate copies of B,

and we have violated the object identity of B, which is not what we want. To get around this problem, a runtime (memory) output database must be kept of all object addresses written to the file. When an object is written to a file, the output database is checked to see if the object has been written out before; if it has, a reference (object identifier) is written to the file instead. That way, when the object is read back the second time, the reader will be able to reference the original object via the input database (see the next section).

Reader function

Note that the entire writer-and-reader scheme is totally dependent on the order of reading exactly duplicating the order of writing. As long as the writer and reader functions are all coded correctly, the order will always be correct, no matter how complex the object reference graph.

Storage Management

Case Example: Borland's Streamable Objects in C++

All persistent classes must have the class TStreamable as one of their direct or indirect base classes. TStreamable defines the pure virtual member functions read(), write(), and streamableName(), which all subclasses must redefine. Furthermore, a streamable class should overload the << and >> (stream I/O operators). Optionally, the streamable class can have a build() member function and a special builder constructor. See table 2 for an explanation of all these functions. All of these (except streamableName()) operate on a special stream library, whose root is class pstream (see fig. 1), that parallels the standard stream library.

Function	Explanation
virtual void* write(opstream)  (protected)	Responsible to write the object out to the opstream. This is usually done by first calling the write() member functions of any direct superclasses, then writing out all data members introduced by the class. Writing out data members is done by calling their << operators on the opstream.
virtual void* read(ipstream)  (protected)	Responsible to read the object from the ipstream in exactly the same order as the write() member function wrote it. This is usually done by first calling the read() member functions of any direct superclasses, then reading in all data members introduced by the class. Reading in data members is done by calling their >> operators on the ipstream.
virtual const char*  streamableName(void)  (private)	Returns the name of the class as a character string for the use of the stream manager.
static TStreamable* build(void)  (public)	Note that build() is a static member function; it is global to the class, not an object, and can be called without reference to a particular object: "<class-name>::build()". build() is used to return an "empty" object -- space is allocated, but nothing is initialized and the constructors are not called for any of the contained objects. This is done by simply returning an instance constructed with the builder constructor. Thus, build is always defined as:  <class-name>* <class-name>::build()    {return new <class-name>(streamableInit);}
builder constructor  (protected)	This is a special constructor which always has the format:   <class-name>(StreamableInit) :     <base-class-name>(...) [,...] {};  which has the effect of calling all the parent constructors, but does not initialize any of the data members. StreamableInit is a special constant used to select this special constructor. This signals the compiler not to initialize the data members.
operator >> (ipstream, <class>)  operator >> (ipstream, <class>*)  operator << (opstream, <classs>)  operator << (opstream, <class>*)	These are the operators that the user of the class actually uses when performing object I/O. They are always defined as:  ipstream operator>>(ipstream is, <class-name> cl)  {return is >> (TStreamable)cl; }  ipstream operator >> (ipstream is, <class-name>* cl)  {return is >> (void*)cl; }  opstream operator<<(opstream os, <class-name> cl)  {return os << (TStreamable)cl; }  opstream operator<<(opstream os, <class-name>* cl)  {return os << (TStreamable*)cl; }

Multiple references

Reading in unallocated objects: build()

TStreamableClass Reg<class-name>("<class-name>",
                                 <class-name>::build,
                                 __DELTA(<class-name>);

#define __link(s) extern TStreamableClass s; \ 
    static struct fLink {fLink *f; TStreamableClass *t;} \ 
    force##s={(fLink*)&force##s, (TStreamableClass*)&s};

Object I/O algorithms

1. The output data base is checked to see if this address has been written before, if it has then the OID is written to the stream, and we are done.
2. The classname (from the streamableInit() virtual member function) is written to the stream.
3. The OID is generated, and written to the stream.
4. The object is output to the stream by calling the object's virtual write() member function.
5. Save the object address and OID in the output database.

1. Look at the next element on the stream. If it is an OID, then the object must already have been read and we need only look up the OID in the input database to determine the memory address. We return a reference to this address and we are done.
2. Otherwise, read in the class name, and construct the object if necessary (see "Reading in unallocated objects").
3. Read in the OID from the stream.
4. The object is read from the stream by calling the object's virtual read() member function.
5. Save the OID and object address in the input database.

Using object I/O

1. make the class known to the stream manager: __link(RegMyClass);
2. open the ofpstream: ofpstream os("myfile.dat");
3. write the object: os << myobject;

1. make the class known to the stream manager: __link(RegMyClass);
2. open the ifpstream: ifpstream is("myfile.dat");
3. declare the object appropriately:

  myClass myObject(StreamableInit); // an instance
  myClass *myObject; // a pointer
4. read the object: is >> myObject;

1. Make the class a subclass of TStreamable
2. Override the virtual member functions read(), write(), streamableName(), and, optionally, static build().
3. Create a special constructor: <class-name>(StreamableInit);
4. Declare a static instance of TStreamableClass: TStreamableClass Reg<class-name>("<class-name>",<class-name>::build,__DELTA(<class-name>));

Possible Extensions to Object I/O

Performance

Auto Read and Write (Transparent Persistence)

• Do all the objects of this type go into the same file? What about instances of subclasses?
• How would we differentiate this instance from all the others in the file? If there are several small instances occurring within different scopes, how does each persistent object's constructor "know" where in the file to find its location in the file? There are several possible schemes. Which is the easiest for an application programmer to use?
• What do we do about objects referencing different object types? The example implementation would fail if each class uses a separate stream because OIDs are local to streams.

Loading Partial Objects

Persistent Name Space

Schema Evolution

Servers

Conclusion

References

[Atwood 91] Atwood, Thomas. "Two Approaches to Adding Persistence to C++." In Implementing Persistent Object Bases: Principles and Practice, the Fourth International Workshop on Persistent Object Systems, September 23-27, 1990, Morgan Kaufmann Publishers Inc, 1991. pp. 369-383.

[Banerjee 87] Banerjee, J. et al. "Data model issues for object-oriented application." ACM Transactions on Office Information Systems, vol. 5, pp.3-26, January, 1987.

[Booch 91] Booch, G. Object oriented design with applications. Benjamin/Cummings, Redwood City, Calif., 1991

[Borland 91] Borland International Inc. ObjectWindows for C++: User's Guide. Scotts Valley, CA., 1991.

[Duex 90] Duex, O. et al. "The story of O2." IEEE Transactions on Knowledge Data Engineering, vol,2, pp.91-108, March 1990.

[DeWitt 86] DeWitt, D.; Carey, M. "Object and file management in the EXODUS extensible database system." In Proceedings of the International Conference on Very Large Data Bases, 1986, pp.91-100.

[Dixon 89] Dixon, G.N.; Parrington, G.D.; Shrivastava, S.K.; Wheater, S.M. "The Treatment of Persistent Objects in Arjuna." The Computer Journal, vol 32, no. 4, 1989. pp.323-332.

[Fishman 87] Fishman, D. et al. "Iris: An object-oriented database management system." ACM Transactions on Office Information Systems, vol.5, pp.48-69, January, 1987.

[Ford 88] Ford, S. et al. "Zeitgeist: Database support for object-oriented programming." In Proceedings of the Second International Workshop on Object-Oriented Database Systems., 1988, pp.23-42.

[Foster 90] Foster, R.K. "TCL Object Input/Output." Journal of the Symantec Programming Languages Association, Fall 1990.

[Joseph 91] Joseph, John V., Thatte, Satish M., Thompson, Craig W., Wells, David L. "Object-Oriented Databases: Design and Implementation." Proceedings of the IEEE, vol 79, no. 1, January 1991. pp 42-63.

[Kim 90] Kim, Won. "Object-Oriented Databases: Definition and Research Directions." IEEE Transactions on Knowledge and Data Engineering, vol. 2, no. 3, September 1990. pp 327-341.

[Moss 88] Moss, J.E.; Sinofsky, S. "Managing persistent data with Mneme: Designing a reliable, shared object interface." in Proceedings of the Second International Workshop on Object-Oriented Database Systems, 1988, pp.298-316.

[Reiss 86] Reiss, S.; Skarra, A.; Zdonik, S. "An object server for an object-oriented database systems." In 1986 International Workshop on Object-Oriented Database Systems, 1986, pp.196-205.

[Schuh 90] Schuh, Dan; Carey, Michael; Dewitt, David. "Persistence in E Revisited -- Implementation Experiences." In Implementing Persistent Object Bases: Principles and Practice, the Fourth International Workshop on Persistent Object Systems, September 23-27, 1990, Morgan Kaufmann Publishers Inc, 1991. pp. 345-359.

[Sequeira 91] Sequeira, Manuel; Marques, Jose Alves. "Can C++ be Used for Programming Distributed and Persistent Objects?." In Proceedings of the International Workshop on Object-Orientation in Operating Systems, Ed. Cabrern, L.F.; Ruso, U.; Shapiro, M. Palo Alto, Ca, Oct 17-18, 1991. pp.173-176.

[Shapiro 89] Shapiro, M.; Gautron, P.; Morsseri, L. "Persistence and Migration for C++ Objects." In ECOOP 89: Proceedings of the Third Conference on Object-Oriented Programming, 1989, Shephen Cook, Ed.

[Stonebraker 86] Stonebraker, M.; Rowe, L. "The design of Postgres." In Proceedings of the 1986 ACM SIGMOD International Conference on Management of Data, 1986, pp.340-355.

[Stroustrup 91] Stroustrup B. The C++ Programming Language (second edition). Addison-Westley, Reading, Mass., 1991.

[Wolf 91] Wolf, Alexander L. "An Initial Look at Abstraction Mechanisms and Persistence." In Implementing Persistent Object Bases: Principles and Practice, the Fourth International Workshop on Persistent Object Systems, September 23-27, 1990, Morgan Kaufmann Publishers Inc, 1991. pp. 360-368.