Java Reference
In-Depth Information
Chapter 23:
Java Data Objects and Transparent
Persistence
In This Chapter
The focus of this chapter is on the transparent persistence and the standard way to achieve it: the Java
data object. After reading this chapter, you should have one more tool in you toolkit to design and
develop enterprise applications.
JDO for Transparent Persistence
So far, you have learned many ways to persist your application data such as Java serialization, JDBC,
entity EJBs, and so on. All these persistence mechanisms require that application programmers know
the details of the underlying database structure; most of them even require programmers to be
responsible for handling the details of persistence. To relieve application programmers from having to
know the details of the database structure, the recently released Java data object (JDO) specification
provides a high level of abstraction:
transparent persistence
.
Transparent persistence means that the persistence of data objects is automatic and that all logic for
processing persistent objects is expressed in pure Java language. The application programmers do not
need to know any database query languages such as SQL. The mapping of Java objects and the
persisted state of objects stored in the database is achieved behind the scene by the JDO provider
implementation and is totally transparent to application developers. From the application developer's
point of view, persistent objects are treated exactly the same as transient objects — instances that only
reside in JVM memory and do not persist outside of an application.
The two major goals of the JDO specification are:
Providing a standard interface between application objects and data stores (for instance, relational
databases, file systems, and so on)
Simplifying secure and scalable applications by providing developers with a Java-centric
mechanism for working with persistent data
Although lower-level abstractions for interacting with databases are still useful, the goal of JDO is to
reduce the need for explicit code for SQL and transaction handling in common business applications.
In addition to shielding the Java developers from the details of the underlying methods for providing
persistence, JDO acts as a standard layer between the application program and any back-end data
stores, whether it be a relational database, an XML database, a legacy application, a file system, or
flash RAM. Applications using the JDO interface can automatically plug in any data store that provides a
JDO implementation. This generally provides portability and increases the longevity of code.
JDO has come a long way to get here. It originated from Java Specification Request (JSR-012),
proposed in 1999. After three years of lengthy Java community process, it was finally approved as an
official specification in March 2002. In the meantime, many other requested specifications have become
standards, and the JDO work force has been dealing with the fact that JDO is able to be integrated into
the frameworks provided by these related specifications (mostly notably J2EE). Indeed, servlets and
session EJBs can directly manipulate JDO persistent instances instead of dealing with the underlying
data stores. Entity EJBs with bean-managed persistence can delegate business logic and persistence
management to JDO classes instead of forcing the developers writing all SQL commands in the
implementation classes. Integration of JDO with J2EE is discussed later in this chapter. First let us see
what makes JDO different from other data persistence mechanisms.
What Makes JDO an Unique Persistence Mechanism
In most cases, instances of Java classes reside in the memory of the running application. They are
destroyed when the program terminates. However, it is often desirable for the objects to persist even
