Charles Lamb Gordon Landis Jack Orenstein Dan Weinreb
Total Page:16
File Type:pdf, Size:1020Kb
Charles Lamb Gordon Landis Jack Orenstein Dan Weinreb SO October 1991/%1.34, No.10/COMMUNICATIONS OF THE ACM bjectStore is an object-oriented database management system (OODBMS) that provides a tightly integrated language interface to the traditional DBMS features of persistent storage, transaction management (concurrency control and recovery), distributed data access, and associative queries. ObjectStore was designed to provide a unified programmatic interface to both persistently allocated data (i.e., data that lives beyond the execution of an applica- tion program) and transiently allocated data (i.e., data that does not survive beyond an application's execution), with object-access speed for persistent data usually equal to that of an in-memory dereference of a pointer to transient data.~-_- ......... - ................. - ....... - ......... - These goals were derived from tain pointers, use C++ virtual to write code that translates be- the requirements of ObjectStore's functions and multiple inheritance, tween the disk-resident representa- target applications, which are typi- etc). In particular, there is no need tion of data, and the representation cally data-intensive programs that to inherit from a special "persistent used during execution. For exam- perform complex manipulations on object" base class. Different objects ple, to store a C+ + object into a re- large databases of objects with intri- of the same type may be persistent lational database, the programmer cate structure, e.g., CAD, CAE, or transient within the same pro- must construct a mapping between CAP, CASE, and geographic infor- gram. the two, and write code that picks mation systems (GIS). This struc- There are several motivations for fields out of tuples and copies them tural complexity is generally real- our goal of making ObjectStore into data members of objects. (This ized by inter-object references, e.g., closely integrated with the pro- is part of the problem that has been pointers from one object to an- gramming language. These in- called the "impedance mismatch" other. Objects are located, possibly clude: between a programming language with the intent to update them, by and a database access language [2, traversing these references and by Ease of learning: It was intention- 13].) With ObjectStore, no translat- associative queries. ally designed so that a C+ + user ing and no copying is needed. Per- We selected C + + as the primary would only have to learn a little bit sistent data is just like ordinary language through which Ob- more in order to try out Ob- heap-allocated (transient) data: jectStore is accessed because it is jectStore and start to use it effec- once a pointer is obtained to it, the becoming a very popular language tively. After that, a user can learn user can just use it in the ordinary among the developers of Ob- more, and take advantage of more way. ObjectStore automatically jectStore's target applications. Ob- of the capabilities the database of- takes care of locking, and keeps jectStore can also be used from C fers. In particular, there is no need track of what has been modified. programs--providing access from to learn a new type system or a new C is easy because the data model of way to define objects. The declara- Expressive power: We wanted the C is a subset of that of C+ +. Use of tive and procedural parts of the interface to persistently allocated ObjectStore from other program- language are used for both kinds of objects to support all of the power ming languages is discussed later. objects. By providing a gradual of the host programming language. The key to ObjectStore's integra- learning path and making it easy This contrasts with the traditional tion with C+ + is that persistence is for users to get started, we hope to data manipulation capabilities of not part of the type of an object. make ObjectStore accessible to a languages such as SQL, which are Objects of any C++ data type wider range of developers, and much less powerful than a general- whatsoever can be allocated tran- help ease the transition into the use purpose programming language. siently (on the ordinary heap) or of object-oriented database tech- persistently (in a database), from nology. Reusability: We wanted to promote built-in types such as integers and reusability of code, by allowing the character strings, to arbitrary user- No translation code: We wanted to same code to operate on either per- defined structures (which may con- save the programmer from having sistent or transient data, and to COMMUNICATIONSOF THE ACM/October 1991/Vol.34, No.10 Sl allow libraries that were developed mance, the target applications are make the speed of dereferencing of for manipulating transient data to very different from traditional pointers to persistent objects be as work on persistent data without database applications such as pay- close as possible to that of transient change. For example, if a program- roll programs and on-line transac- objects, namely the speed of a sin- mer has a library routine that takes tion processing systems, in several gle load instruction. an array of floating-point numbers ways, as we found from interview- ObjectStore also has some of the and computes the fast Fourier ing developers of such applications. same performance goals as ordi- transforra, he or she can pass it an nary relational DBMSs, and it gen- Temporal locality: When many ObjectStore persistent array, and it erally accomplishes these using will work. Usually, if a library does users access a shared database, very familiar techniques such as indexes, often the next user of a data item not need to do any persistent allo- query optimization, log-based re- cation of its own, the library can be will be the same as the previous covery, and so on. The implemen- applied to persistent data without user. In other words, while concur- tation section explains how we ap- even being recompiled. rent access must be allowed and proached all of these performance must work correctly, many data goals, focusing on the aspects of Conversion: Many programmers items will be used 'mostly' by one ObjectStore that differ from con- who are interested in using object- user over a short span of time. ventional techniques. oriented DBMSs would like to add Spatial locality: Often an applica- Another goal of ObjectStore is to persistence to existing applications tion will use only a portion of a provide several features that are that deal with transient objects, database, and that portion will be missing from C++ and from most rather than build new applications (or can be arranged to be) in a small DBMSs: a collection facility (sets, from scratch. We wanted to make it section of the database that is con- lists, and so on), a way to express as easy as possible to convert an ex- tiguous, or mostly so. bidirectional relationships, and isting application to use persistent support for groupware based on objects throughout. In particular, Fine interleaving: Applications versioned data. this means that basic data opera- often interleave small database op- tions such as dereferencing point- erations (i.e., go from one object to Application Interface ers and getting and setting data a reference object) with small In addition to the data definition members should be syntactically the amounts of computation. That is, and manipulation facilities pro- same for persistent and transient there are many very small database vided by the host languages, C and objects, and that variables should operations rather than relatively C++, ObjectStore provides sup- not have 1:o have their type declara- few large ones. If every database port for accessing persistent data tions changed when persistent ob- operation required a significant inside transactions, a library of col- jects are used. per-operation overhead cost (such lection types, bidirectional relation- as the cost of sending a network ships, an optimizing query facility, Type checking: We wanted the message), overhead costs would and a version facility to support col- compile-time type-checking of become prohibitive. laborative work. Tools supporting C+ + to apply to persistent data as Developers told us that it is im- database schema design, database well as transient data, with the en- perative that ordinary data manip- browsing, database administration, tire application using a single type ulation be as fast as possible. For and application compilation and system. The compiler's type check- example, an ECAD circuit simula- debugging, are also provided. ing applies to objects in the data- tion is CPU-intensive, traversing a There are three programming base. For example, a variable refer- network of objects representing a interfaces supported, a C library ring to an object of class employee circuit, carrying out computations interface, a C++ library interface, would have type 'employee *'. Such on the way. These simulations are and an extended C+ + which pro- a variable could refer to a persistent quite expensive. Any approach to vides a tighter language integration employee or a transient employee, data management that penalizes to the query and relationship facili- at different times during program the running time of such an appli- ties. This interface is accessible only execution. A function that takes a cation is impractical. This means through ObjectStore's C++ com- reference to an employee as an ar- that one critical operation must be piler, while the two library inter- gument can therefore operate on a as fast as possible: the operation of faces are accessible through other persistent or a transient employee. obtaining data from an object, third-party C or C++ compilers, The second goal of ObjectStore given a pointer or reference to the thus providing maximum portabil- is to provide a very high perfor- object. This operation might be ity.