ObjectDatabase++ (ODBPP) is an embeddable object-oriented database designed for server applications that require minimal external maintenance. It is written in C++ as a real-time ISAM level database with the ability to auto recover from system crashes while maintaining database integrity. Its unique transaction process allows for maintenance of both the indexes and tables, preventing double allocation of index entries that could prohibit rollback of transactions.

Features of ODBPP include: full multi-process and multi-thread transaction control, auto real-time database recovery, hierarchical object data design, native code and script access, static hash index on object IDs, numerous supported index methods including full-text and biometric pattern matching.

ODBPP supports objects that are hierarchical in design, similar to XML, JSON or serialized PHP. It is this hierarchical object that separates object databases from their relational cousins and it is the process of keeping the entire object in one record rather than spreading it out over multiple tables that give object databases the distinction from the relational model.

Traditionally databases have been designed with the relational model. This would separate data over several tables and use a common identifier to relate all the child records back to their parent. These model was based on each row within the table containing individual pieces of data. SQL databases based on this design would create joins that would reconnect the entire relation back together, suffering performance limitations.

In the object database design, instead of using multiple tables to store a data object, it is stored in one a single record. This keeps the entire object intact and reducing the need to join the data back together. This process of storing the entire object in one table reduces the total amount to lock, reads and write operations required. It is also this ability to store an object in one record that reduce the amount of file reads and writes, which enables the object design to maintain efficiency with very large and very complex database designs.

Looking at the images to the right, the on above depicts the relational model and has the data spread over two tables, with the parent in amber and the children in blue. In the object model, both the parent and children are stored in the one data record, the information that was previously stored within the related table is now stored within the sub or nested table of Foo.

ODBPP implements a transaction control that allows for process to continue while another is terminated. This unique transaction control allows the continuing process to identify the terminated transaction, recover database integrity and continue mid transaction. It is this ability to terminate transaction at any point that enables real-time transactions implementation by server using the method.

The transaction control utilizes four separate file to implement the entire process and flushed each change of state to the drive before continuing to the next state. This creates a time consuming process where each individual write to a file has three separate states and the entire transaction is required to pass through three separate files. Initially all adds, edit and deletes are written a shared memory file, this enables all transaction to know if a resource, such as an index value has been allocated. This memory file can be destroy when the OS starts without interfering with the database integrity, and is only used for IPC purposes.