What Is JDO?

JDO specifies a persistence service for those objects whose state outlives the lifetime of a single invocation of a Java Virtual Machine (JVM). Nearly every program saves the state of some objects and either restores this state on a subsequent invocation or shares it with another concurrently running program. The state preserved is both the state within objects and the relationships between objects.

JDO is a persistence service because it connects Java objects in memory to the long-term storage of their state. By using a service that is concerned only with persistence, applications can isolate the work of moving state between memory and a datastore to one area of code. Without a persistence service, the code to interface with the datastore is spread throughout the application. By using JDO, the application programmer can make persistence a modular component. As a result, the maintainability of the application improves. It is easier to find bugs, fix them, avoid introducing new bugs, and upgrade the capabilities of the application.

Although most applications need to persist some objects, not all objects require persistence. Many objects in a program are simply transient, which means their state is created as needed and discarded when the program stops executing, if not before. Some objects are transient but use persistent objects or the information in them. For example, an object that sums the sales figures from a collection of persistent invoices may itself be transient.

JDO Specifies a Uniform Persistence Service

JDO specifies an Application Programming Interface (API) to a library of services that the application program can use for persistence. JDO also specifies the persistent services that are provided transparently to all persistent objects. JDO ships with a reference implementation of this API that may be suitable for prototype development. Numerous vendors have created new products or adapted existing products to support the JDO specification. These products will compete against each other in terms of robustness, performance, supported datastores, support for optional JDO features, ease of configuration, flexibility, and so forth.

JDO encapsulates and simplifies the programming issues that are unique to persistent objects. It provides a service to find, update, and delete existing persistent objects and to store new persistent objects. It encapsulates the mapping of object state in memory to persistent state in the datastore. It ensures that multiple changes made to persistent objects in memory are stored in an all-or-nothing fashion in the datastore. Lastly, it allows multiple concurrently executing applications and threads to share access to the persistent state.

JDO offers a uniform set of persistence services that do not vary with the datastore used or the deployment environment chosen. JDO implementations can be built for a variety of datastore architectures, such as files, object databases, relational databases, and generalized transaction processing services. Because JDO encapsulates the datastore, it allows the application to use the same set of services regardless of the datastore selected. The uniformity of JDO allows the application to remain blissfully ignorant of the differences in query languages, data models, and access interfaces between the various datastores. When it comes to deployment architectures, application code that uses JDO may be deployed in stand-alone applications, client/server applications, servlets, and Enterprise JavaBeans (EJBs). For the most part, the same set of JDO services is available in all of these environments.

A Large Part of JDO's Persistence Service Is Transparent

When using JDO, the application programmer does not write persistence-related code in the application data classes—these are the classes that define the objects that have persistent state. Instead, the programmer creates the application data classes as if persistence were not an issue. He declares the fields that contain the object's state and writes the methods to access and modify the state of the object in memory.

JDO requires an enhancement step for all application data classes. The JDO vendor supplies a tool, called the enhancer, that the programmer uses to add the persistence-related code to application data classes. As a result of enhancement, JDO can manage the application data objects as persistent objects. Because enhancement usually occurs after compilation, persistence-related code is usually not visible in the source code of the application data classes.

Transparent persistence is powerful because it requires no coding by the application programmer and because it imposes few design and coding constraints. When an application uses JDO, persistence code is effectively absent in the source code of application data classes. Yet, at runtime, the data objects are alive. They can be fetched from the datastore by queries or identity. If one persistent object references another, the reference is instantiated transparently when used. When a transaction is active, the data object's persistent state is transactionally consistent with the datastore, and modifications made to it will be reflected in the datastore when the transaction is committed.