Java Data Objects (JDO)

The last persistence technology that you will be looking at today, Java Data Objects (JDO), aims high and aims low. That is, it is intended both for use within embedded devices (J2ME), but also for use within J2EE environments. In a J2EE environment, JDO can either supplement or supplant Entity EJBs. If supplementing Entity EJBs, the application of JDO may be hidden when CMP is being employed (that is, the EJB vendor uses JDO but the bean provider is unaware of this), or it can be used by the bean provider directly if BMP is in use. If supplanting Entity EJBs, JDO can be used directly from Session EJBs and servlets.

The overriding objective of JDO is to provide persistence transparency. In other words, the objects that are to persist— also called persistent-capable objects—do not need to include any logic to make them persistent. Contrast this with EJB Entity beans that need to implement ejbLoad() and ejbStore(), or with EJB Session beans (and for that matter servlets) that require large numbers of JDBC or SQLj calls. The only classes that need to use the JDO interfaces and classes are those that manage the lifecycle of persistent objects. Also, JDO does not require the programmer to write SQL in order to access the database. This will enhance portability and platform independence, as differences between the database vendor's SQL implementations will be hidden.

JDO's approach to object persistence revolves around the concept of a cache. This cache belongs to a client, rather than the server; the objects in the cache are not shared among all clients. In a J2EE environment, a stateful Session bean would usually be a client; each active Session bean would have its own cache. At any given time, the cache that holds the objects is associated with, at most, one connection and, at most, one transaction. Over time, that cache can be used with different transactions, and, for that matter, with different connections.

The JDO API is defined by classes and interfaces in the javax.jdo package. Some of the interfaces are for the JDO vendor to implement and some for the application developer (but more on this in a moment). The JDO interface that controls the client's cache is javax.jdo.PersistenceManager. In a J2EE environment, an instance of this interface is obtained from a javax.jdo.PersistenceManagerFactory that, in turn, is obtained via JNDI.

As a brief taster of how JDO can be used, Listing 8.6 shows the basic steps to create a new persistence-capable Customer for the Agency case study.

Listing 8.6. Using JDO to Create a New Customer

// import javax.jdo.*;
// import javax.naming.*;

Context ctx = new InitialContext();
PersistenceManagerFactory pmf = (PersistenceManagerFactory)
    ctx.lookup("java:comp/env/jdo/SomePersistenceManagerFactory";
PersistenceManager pm = pmf.getPersistenceManager();

Transaction txn = pm.currentTransaction();
txn.begin();
Customer customer = new Customer(login, address1, address2, email, name);
pm.makePersistent(customer);
txn.commit();

As well as being able to create new objects, JDO also provides the capability to find existing objects. This is not surprising; after all, the home interface offers the finder methods, as well as the create methods, in EJB.

Rather than defining a declarative language, such as SQL or EJBQL, JDO uses a Java API approach.

As an example, Listing 8.7 shows two queries. The first identifies all jobs that have a customer of "winston"; the second finds all jobs that require "Cigar Trimmer" as a skill.

Listing 8.7. Using JDO to Search for Jobs that Meet Some Criteria

// import javax.jdo.*;
// import javax.naming.*;

Context ctx = new InitialContext();
PersistenceManagerFactory pmf = (PersistenceManagerFactory)
    ctx.lookup("java:comp/env/jdo/SomePersistenceManagerFactory";
PersistenceManager pm = pmf.getPersistenceManager();

Transaction txn = pm.currentTransaction();
txn.begin();

// query #1: all jobs that have a customer of "winston".
Query query1 = pm.newQuery();
query1.setClass(Job.class);
Extent candidateJobs = pm.getExtent(Job.class, false);
query1.setCandidates(candidateJobs);
query1.declareParameters("String nameParam");
query1.setFilter( "customer == nameParam ");
Collection query1Res = (Collection) query.execute("winston");
for(Iterator iter = query1Res.iterator(); iter.hasNext(); ) {
    Job job = (Job)iter.next();
    System.out.println(job.getRef());
}

// query #2: all jobs that require "Cigar Trimmer" as a skill
Query query2 = pm.newQuery(Job.class, candidateJobs);
query2.declareVariables("Skill eachSkill");
query2.setFilter(
    "skills.contains(eachSkill) && eachSkill.name == "Cigar Trimmer"");
Collection query2Res = (Collection) query.execute();
for(Iterator iter = query2Res.iterator(); iter.hasNext(); ) {
    Job job = (Job)iter.next();
    System.out.println(job.getRef());
}
txn.commit();

There is much more in JDO than there is room to cover here. Some aspects worth a brief mention include the following:

• Deployment descriptors— A deployment descriptor is used for each persistence-capable application class. This identifies the fields that are persistent rather than transient, the JDO identity type, and other information required for the JDO enhancer.

• Lifecycle— Persistent-capable objects go through different stages of their lifecycle. For example, when an object is first instantiated, it is in the transient state. When the PersistenceManager.makePersistent() method is called, the object transitions to persistent-new state. One state, hollow, is very similar to the EJB notion of a passivated Entity bean.

• Transient transactional objects— These are transactional objects acting in a manner akin to a ShoppingCart Session bean whose implementation supports automatic transaction recovery (implementing javax.ejb.SessionSynchronization).