Persist data with Java Data Objects, Part 2

Sun JDO vs. Castor JDO

By Jacek Kruszelnicki, JavaWorld.com, 04/12/02

Page 2 of 8

A good example of a first-class object: an object of class Order. An Order usually has one or more instances of OrderLine items. OrderLine is a second-class object example.

Now, I'll detail the specification's major public interfaces:

• PersistenceManagerFactory
• PersistenceManager
• PersistenceCapable
• Transaction
• Query

PersistenceManagerFactory

The PersistenceManagerFactory creates PersistenceManager instances for application use. It also lets application developers configure the persistence layer behavior -- set transaction options, perform connection pool administration, and so on.

In a managed environment, the application uses JNDI (Java Naming and Directory Interface) lookup to retrieve an environment-named object, which is then cast to javax.jdo.PersistenceManagerFactory.

PersistenceManager

The JDO PersistenceManager provides the primary interface for JDO-aware application components. PersistenceManager administers persistent instances' lifecycles, and provides transaction and cache management. It also acts as the Query interface's factory.

PersistenceCapable

As mentioned before, any user domain class must implement the PersistenceCapable interface. Note: There are no special methods for persistence; the PersistenceCapable interface is really empty. You can implement this interface in one of three ways: through source code, an enhancer, or generation (tool-based).

Transaction

Persistence operations usually occur within a transactional context. A one-to-one relationship exists between the PersistenceManager and the Transaction. In managed environments, the container provides actual transaction services, but the Transaction interface provides methods for managing transaction options. In a standalone environment, the Transaction implementation, provided by the JDO software vendor, must ensure a successful transaction -- commit or rollback.

Cache management and JDO instance lifecycle
Every JDO object (instance) goes through a series of state changes in its lifetime. The Sun JDO specification defines 10 JDO instance states. It requires seven transactional instance states (the remaining three are optional):

• Transient: When an instance is transient, the object lacks persistent identity. A transient instance changes its state to persistent-new (see below) in one of two ways: when passed as an argument to the makePersistent() method or when referenced by a persistent instance's persistent field after that same instance commits.
• Persistent-new: An instance that is newly persistent in the current transaction. When an application component requests an instance to become persistent, that instance assumes the persistent-new state and receives a persistent identity.
• Persistent-dirty: An instance's state when one or more of its attributes have changed (within the current transaction), but not yet persisted.
• Hollow: A JDO instance that represents specific persistent data in the data store, but whose values are not in the JDO instance.
• Persistent-clean: A JDO instance that represents specific transactional persistent data in the data store, and whose values have not changed (within the current transaction).
• Persistent-deleted: JDO instances that represent specific persistent data in the data store and have been deleted in the current transaction.
• Persistent-new-deleted: JDO instances that represent new persistent instances deleted from the current transaction.

For more information regarding state transitions and JDO instances' persistence states, consult the Sun JDO spec.

Query

An important part of every data manipulation subsystem is its query language. In the Sun JDO, the PersistentManager instance is a factory for query instances, and queries execute in the context of the PersistentManager instance.

Queries must conform to the Object Query Language (OQL) grammar, defined in the Object Management Group (OMG) 3.0 OQL Specification. The JDO OQL resembles SQL, except that it operates on Java classes and objects, not tables. A JDO OQL query has at least three elements:

• Class of result.
• JDO instances' candidate collection (usually extent).
• Query filter.

Optional query elements include the following:

• Parameter declaration(s) (follows formal Java syntax parameters).
• Value(s) to be bound.
• Ordering specification.

Query filters can be the following:

• Names of instance fields in the Java objects.
• Operators (a subset of Java operators, for example: ==, !=, >, ||, and so on). Of course not all Java operators make sense for data selection.

Please consult the JDO spec for more details regarding queries.

Below is a JDO query example:

 // Example of a query
Class target = Employee.class;
Extent extent = pm.getExtent (target, false);
String filter = "getEmpId () >= 1 && getEmpId () <= 10";
Query query = pm.newQuery (extent, filter);
query.setClass (target);
query.compile ();
Collection result = (Collection) query.execute ();

Sun JDO: The good, the bad, and the ugly

Let's see how the Sun JDO compares to the ideal persistence layer presented in Part 1. As you might recall, the desirable traits I outlined include the following (Note: I reference only the most important features):