EE Explorer: Persistent data management, part 2nd

Application components should implement requests for enterprise Services. To implement these requests, application components often have to change the state of the underlying data store. These changes must not destroy the integrity of persistent data stores. (In the first article on data persistence, we defined a persistent data store as a separate data resource pool that protects data even when a server crashes or a network fails.) To ensure durability, application components must be able to handle concurrency, connection management, data integrity, and synchronization. Java EE's three data management technologies can handle these functions for developers, except that each technology has its own approach.

Last month we explored the pros and cons of entity beans and JDBC. This month, we'll look at how Java data objects are combined with stateless session beans, and how the solution compares to a standard entity bean application. Since JDO is still a fairly new technology (the latest Java EE persistence solution), we'll begin by outlining how it works.

JDO Overview

The relationship between Java applications and persistent data management has long been difficult to deal with. Many persistence mechanisms store data in relational methods rather than object-oriented methods. That is, the data is stored in a table that consists of records that contain fields, not as self-contained objects, which have internal data and references to other objects, and other objects have internal data and references. Translating an object-oriented representation into a relational representation has been cumbersome, error-prone, and degrades application performance. Until recently, a handful of persistence mechanisms, essentially non-relational, such as SQL blobs and Java serialization, were cumbersome to use. Most persistence mechanisms allow developers to handle persistence or interact with back-end data storage using a non-Java language such as SQL.

The advantage of JDO is that it's simple. Developers use the Java language to persist object instances and retrieve instances from memory. Processing logic, synchronization, and failover are handled transparently. Instead of using the inconvenient serialization mechanism provided by SQL or the Java language, developers use only POJO (plain Java objects), the JDO interface is used to pass object references to memory and retrieve object references from memory.

JDO also employs a number of advanced architectures used by JDBC. It uses an pluggable architecture in which developers write their own code as a standard interface set (the JDO API), and vendors provide implementations of these interfaces. This allows applications that use the JDO interface to "insert" any data store that supports the JDO API. Like JDBC, this makes porting easier and fosters competition among vendors to produce better products because vendors strive to deliver more efficient and powerful implementations.

Session Beans and JDO

Session beans are the backbone of any Java EE architecture that incorporates EJB technology. This is especially true for stateless session beans. As discussed earlier, the stability and predictability of stateless session beans makes them particularly suitable for managing persistent enterprise data.

However, the session bean itself cannot access persistent data stores. They must be combined with other technologies, such as entity beans, JDBC, or JDO, to create a persistent data management mechanism. Combining session beans with JDO is similar to combining them with JDBC, but JDO handles the issue in a more object-oriented and Java-centric perspective.

A powerful combination

The enterprise bean obtains access to external resources by requesting the resource Manager to connect to the factory with the EJB container. EJB components that use JDBC do so, too, with the use of JDO EJB components. The first thing the session Bean must do is to get a reference to persistencemanagerfactory by invoking the JNDI query. The PersistenceManager instance is then obtained from the factory. If the session bean is using a container-managed transaction, each business method will use the factory to obtain a new PersistenceManager instance, and then close the instance before exiting the method. If you are using a bean-managed transaction, the developer determines the start and end conditions for the transaction. Therefore, you can use the same PersistenceManager instance in multiple business method invocations. Similarly, you can open and manage multiple transactions in one business method. The PersistenceManager API supports all of these scenarios.

The JDO API that interacts with PersistenceManager is simple and intuitive. The developer makes the object persistent by calling the Makepersistent () method. Also, this method signature is overloaded, allowing the various object types to be treated as persistent objects (a single object, an array of objects, or a collection of objects). Retrieving objects is also simple. The Getobjectbyid () method distinguishes an object instance using a unique value determined by the developer (similar to a primary key). JDO also supports query-based queries that retrieve a single object or collection of objects based on the specified type (that is, subclasses and classes that implement the public interface). Like JDBC, JDO supports basic transactional controls: Begin (), commit (), and rollback (), and indicate whether the PersistenceManager instance should use optimistic or pessimistic transaction management methods.