This chapter introduces the basic concepts you need to understand in order to use ObjectStore successfully. The information is organized as conceptual overviews of the following topics:

• Persistent Storage
• ObjectStore Processes
• Rawfs Databases
• ObjectStore Memory Mapping Architecture
• Memory Mapping and Schema Information
• Generating Schemas for ObjectStore Applications
• Programming Interface

Each database is made up of segments, which are variable-sized regions of memory that can be used as the unit of transfer from persistent storage to program, or transient, memory. Each segment, in turn, is made up of pages. A specified number of pages can be used instead of segments as the unit of transfer to program memory.

ObjectStore Processes

A Cache Manager is started automatically when an ObjectStore application starts. The cache manager is a daemon that runs on the machine running the client application. Its function is to respond to Server requests as a stand-in for the client application, in order to participate in the management of the application's client cache. The client cache is the local holding area for data mapped or waiting to be mapped into virtual memory.

If additional ObjectStore applications are started on the same machine, the same Cache Manager functions similarly for these applications as well. Although the same machine can run several ObjectStore applications at once, only a single Cache Manager is ever running on a given machine. As with Servers, most users never have to worry about starting or stopping Cache Managers.

ObjectStore/Single

ObjectStore processes

ObjectStore/Single process

The nonnetworked ObjectStore/Single application provides the same functions, but the two processes have been combined into one.

Rawfs Databases

Each rawfs provides a separate name space and directory hierarchy. Rawfs directories form hierarchical structures just as operating system directories do. But rawfs directory hierarchies are independent of the operating system directory hierarchies.

Each ObjectStore Server can manage a hierarchy of rawfs directories, and maintains permission modes, creation dates, owners, and groups for each entry. There can be several independent rawfs directory hierarchies at a given site, each managed by a different Server, and the same application can use databases in different hierarchies.

ObjectStore/Single

ObjectStore Memory Mapping Architecture

Sometimes the referenced data is already in the client cache (because data in the same pages was already used, and the required page was not swapped out of the cache), and all that is required is the virtual memory mapping. Sometimes the data is already mapped into virtual memory (because data on the same page was already used in the current transaction) and then nothing additional is required to access it. Once data has been mapped into virtual memory, access to it is as fast as access to regular, transient data.

The paragraphs that follow provide a summary of how the transfer of data between persistent and transient memory is handled.

ObjectStore achieves the combination of transparency and efficiency with a unique memory mapping architecture. All data is stored in an ObjectStore database in its native C++ format. All pointers in a database take the form of regular virtual memory pointers. The value of a pointer in a given segment is the segment's pseudoaddress for the object the pointer refers to.

Pseudoaddresses

Relocation is the process of changing the pointers on a page of data as it is mapped into the client cache or unmapped from the client cache. Here is how relocation works.

Persistent relocation map (PRM)

When a page of data is mapped into the cache, all pseudoaddresses on the page must be converted into virtual addresses within the process's persistent address space region. Within a transaction, a single unified mapping (across all segments) that establishes the translation between database location (again, database name, segment number, and offset) to virtual address is built up. Also, for each segment, a transient mapping that establishes the direct bidirectional translation between pseudoaddresses and virtual addresses is built up. The manner in which these mappings are built depends on whether the segment is using

• Immediate address-space assignment
• Deferred address-space assignment

With deferred assignment, the unified mapping and the pseudoaddress-to-virtual-address mapping are augmented from the segment's PRM as necessary to translate each pseudoaddress encountered during the relocation. In both cases, each pointer (pseudoaddress) on the page being relocated is changed to the virtual address determined by its on-disk location and the transient mappings described above. Once inbound relocation is complete, the page is mapped into virtual memory at the location assigned it by the unified mapping.

Outbound relocation

Transient relocation map (TRM)

Advantages of this architecture

• Persistence is specified on a per-instance basis, independent of type. The same type can have both persistent and nonpersistent instances, and the same function can operate on both persistent and nonpersistent data. Moreover, instances of any built-in C++ type (such as int) can be designated as persistent. This means that your existing routines, developed for use with transient data, can also be used in ObjectStore applications.
• Pointers are processed at memory speeds. Once an object has been transferred and mapped into virtual memory, all pointers to it are regular virtual memory pointers, and are processed at regular hardware speeds, with none of the overhead associated with soft pointer schemes, and no continual checking for database references.

ObjectStore stores schema information as C++ objects. Classes themselves are not run-time objects in C++ (they cannot, for example, be values of variables or other expressions). So ObjectStore must generate representations of classes in order to manage database memory.

These representations are generated, before link time, for each application that might store information in a database. So, at run time, when the application stores an object in a database, a representation of the object's class is ready to be added to the database's schema along with the object itself; or, if instances of that class are already in the database, the application's class representation is checked against that of the database to make sure they agree.

An application's schema information (generated by the ObjectStore schema generator) is stored in two places: a source file and an ObjectStore database. Because you must use the schema generator when building an ObjectStore application, you are making use of ObjectStore's database management capabilities, which are described in ObjectStore Management.

Generating Schemas for ObjectStore Applications

Input to Schema Generation

By performing a transitive closure operation, the schema generator determines all those classes reachable by navigation from the classes in the schema source file, and adds information about them to the application schema database.

Library schemas are ObjectStore databases that contain schema information for libraries that store or retrieve persistent data. ObjectStore provides library schemas for its libraries. You can also use the schema generator to generate library schemas for other libraries.

Schema Generator Output

For complete instructions on building ObjectStore applications and libraries, see ObjectStore Building C++ Interface Applications. In particular, there is a good summary of tasks in Chapter 1, Overview of Building an Application. The process of schema generation itself is discussed in detail in Chapter 3, Generating Schemas, of that publication.

Programming Interface

With ObjectStore and ObjectStore/Single, you can use a variety of C++ compilers, together with the C++ library interface. This is a library of classes whose member functions, data members, and enumerators provide access to database functionality. Also included are global functions, such as an overloading of operator new() that allows dynamic allocation of persistent memory for any type of object.

The class templates feature of C++ is included in the ANSI Standard for C++. If you are using a compiler that supports templates, you can use the parameterized versions of some classes in the class library. Using parameterized classes enhances the type safety of your applications.

Updated: 03/31/98 16:53:06