Object Oriented Database Learning Center

Objectivity Home - Government - Objectivity/DB - Webinars - Download Software

Table of contents:

Building High-perfomance Object Oriented Databases

An Object-oriented approach to persistence: Objectivity/DB takes an object-oriented approach, which preserves the advantages of the previous solutions and avoids the disadvantages. That is, Objectivity/DB allows objects to keep lists of the objects they reference. However, the referenced objects are identified logically, and not with physical addresses.

The problem with maintaining physical addresses is really the same problem that software developers have with memory management. For years, software developers have solved the problems by replacing pointers with handles.

Handles are pointers to pointers that uniquely identify an object, but the layer of indirection means that the handles don’t directly point to a location in memory (or in Objectivity/DB’s case – on disk). This allows software to re-allocate memory without modifying the object ID, so the address can be changed in a single place instead of modifying all the references to the object.

Because each element has its own list of elements it’s connected to, traversing from one element to another is fast, lightweight and relatively painless with no need for extra memory-consuming indexes that are slow to update.

Managing concurrency while updating an object's list of references is much simpler as well, because only the updated object needs to be locked. There is no need for locking an entire segment of an index, so Objectivity/DB can use pessimistic locking (described further in the section titled Concurrency).

A closer look at object identifiers: Objectivity/DB’s “persistent handles” are called Object Identifiers, or OIDs. Each OID is assigned when a new object is first placed into the database. In C++, this is almost always when the object is first created. In Java, this would be when the object is “clustered”.

Each OID consists of four 16-bit fields, where each field represents a level in the logical organization of objects in Objectivity/DB. This logical organization consists of a hierarchy of storage structures. An “Objectivity/DB database” is actually a federation of databases, where each database is normally a single file in which objects are stored. Each database is subdivided into containers, and each container is subdivided into pages. A page is Objectivity/DB's unit of transfer from disk to application memory. Individual objects are stored in slots on a page.

The first field in the OID represents the database ID, the second represents the container within the database, the third the logical page within the container, and the fourth is a logical slot within the page. Once the OID is assigned, it’s permanent for the life of the object, regardless of how often its attributes change.

An Objectivity/DB container is a group of objects within a database. Since a container can have 16-bits worth of pages, a container can hold 65,536 pages worth of objects (minus a few for Objectivity/DB’s internal use). Depending on the page size, a container can hold almost 4 gigabytes of objects.

Objectivity/DB containers provide to a database what shelves provide to a closet and what directories provide to a file system. They’re an extremely flexible way to organize information as objects.

At the beginning of each container, Objectivity/DB stores a page map, represented in Figure 5. The page map is the first layer of indirection that allows Objectivity/DB to avoid the rigidity of hierarchical databases by assigning the logical page (the page ID in each OID) to a physical page.

When a page is updated, Objectivity/DB can simply write the new page to disk, rather than overwriting the old one. When a user “commits” a change to the object, Objectivity simply changes the page map to point the constant logical page to the new physical page. This basic architecture has many advantages that we’ll discuss further in the following sections.