Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
In Part 1, I provided an overview of available persistence mechanisms and their implementations, and introduced the Java Data Objects (JDO) approach to persistence. In Part 2, I conclude this series by looking more closely at the two competing JDO standards: the Sun Microsystems JDO and the Castor JDO. Both specifications provide unified, simple, and transparent persistence interfaces between Java application objects and data stores, and create an interesting alternative to entity beans.
Read the whole series on Java Data Objects:
The Sun JDO architecture provides application programmers a Java-centric view of persistent information. Sun's specification defines a standard API for data contained in various enterprise information systems, such as enterprise resource planning, mainframe transaction processing, and database systems. The architecture also follows the Java Connector Architecture (JCA), which defines a mechanism set for integrating an executive information system with an application server.
Figure 1 illustrates the Sun JDO architecture. The specification allows multiple JDO implementations -- possibly attached to different data stores -- to be plugged into an application server or used directly in a two-tier architecture. This approach lets application components access the underlying data stores using one consistent Java-centric data view. The JDO implementation provides the necessary mapping from Java objects into the underlying data store's special data types and relationships.
Figure 1. The Sun JDO architecture. Click on thumbnail to view full-sized image.
Before delving into the Sun JDO interfaces, I discuss the specification's three fundamental concepts:
A JDO instance is a Java class instance that implements the application functions and represents data in an enterprise data
store. A JDO instance has an important limitation: its class must always implement the
PersistenceCapable interface (defined below), either explicitly by the class writer or implicitly by the enhancer's results.
Instances of the
PersistenceCapable classes that have JDO identity represent first-class objects; these objects are stored in a data store with their associated
second-class objects (if any) and primitive values. First-class objects are unique: when a
PersistentManager (defined below) instantiates one into memory, that same
PersistentManager manages an instance representing that first-class object, though other
PersistentManagers might manage other instances of that same class.
PersistenceCapable instances, second-class objects differ from first-class objects in that they have no JDO identity of their own. Second-class
objects notify their first-class objects of their modification; that modification reflects as a change to that first-class
object. Second-class objects are stored in the data store as part of a first-class object only.