Object Database Programming
with the
ODMG Java Binding

David Wallace Croft
Senior Intelligent Systems Engineer
Special Projects Division, Information Technology
Analytic Services, Inc. (ANSER)



When using an object-oriented programming language such as Java, it is desirable to use an Object Database Management System (ODBMS) for object persistence. The Object Data Management Group, a sister organization of the Object Management Group that brought forth CORBA, has defined a Java binding for their object database programming standard, ODMG 2.0. There is a close correlation between the ODMG Java API and the new Java 2 Collections classes; this will facilitate platform independence when ODMG 2.1 and ODMG 3.0 are implemented. In addition, ODMG 2.0 defines the Object Query Language (OQL) which is recognizable as a derivative of the Structured Query Language (SQL) for relational databases.

One of the ODBMS vendors which supports the ODMG standard, including server-side OQL processing, is POET. The current POET software will be used as the implementation example throughout this work.


The Java 2 Collections classes are a set of data container objects that support the concept of "generic programming", the storage and manipulation of objects as their generic Object superclass. Examples of such container objects that were present in Java 1 include the familiar java.util package classes such as Enumeration, Hashtable, and Vector.

With Java 2, a further abstraction of the classes has been made by introducing new interfaces such as Collection, Iterator, List, Map, and Set. The Java 1 classes have been retrofitted to implement these interfaces thereby allowing better support for programming through polymorphism and compositon. In addition, the java.util package has been supplemented by new concrete classes such as HashSet and LinkedList.

The ODMG 2.1 standard introduces new collections interfaces which extend their Java 2 counterparts, providing additional methods such as set operations (union, intersection, difference). Portability using the ODMG 2.0 standard may be implemented using custom adapter classes.

ODMG Interface Extends... Description
DCollection java.util.Collection superclass to add/remove objects
DSet DCollection, java.util.Set unordered, no duplicates
DBag DCollection unordered, duplicates
DList DCollection, java.util.List ordered, variable size
DArray DCollection, java.util.List ordered, fixed size

ODMG Java Binding

As the ODMG Java binding allows for object database manipulation without the need for the integration of a distinct embedded database language, normal Java classes and objects may be used without the need to implement special interfaces or keywords beyond what the Java language already defines. For example, a root object to be made persistent, and all of its primitives and objects within its object graph reachable through its instance variables, are automatically stored excepting those that are defined as being "transient" using the standard Java attribute of the same name.

Usually such root objects are collections objects that are stored and retrieved from the database using a name unique to the database that is assigned and bound by the application. Such named objects are retrieved within the scope of a Transaction and from thereon object manipulations of the object and all objects reachable through its object graph are performed through the normal Java object operations such as accessor and mutator method calling. Changes to the object graph are committed using methods on the Transaction object such as commit() and checkpoint(). In addition, Transactions may be aborted leaving the persistent version of the object unchanged despite multiple manipulations to the transient representation.

As modifications to persistent objects are only reflected within the database when Transactions are committed, care must be taken to define the locking level to permit simultaneous shared access by multiple threads. Examples of locking attributes include read-only, read-write, and others. Vendor-specific implementations will offer additional locking granularity and strategies.

classes which manipulate object persistence must also be preprocessed unbind removes name, but object still exists


index search

on server, not client

POET Implementation

configuration file declares which classes persistent

preprocessor uses ptjavac.opt

dictionary file

database file

ODBC Driver

SQL Object Factory

classes can change over time without breaking the database

student level available?

POET Navajo:  pure Java, automated persistent garbage collection



David Wallace Croft, croftd@nexos.anser.org
© 1999 Analytic Services, Inc. (ANSER)
Posted 1999-01-24.