Comparison between the two major JDO architectures
Tutorial Details:
Persist data with Java Data Objects, Part 2
Persist data with Java Data Objects, Part 2
By: By Jacek Kruszelnicki
Sun JDO vs. Castor JDO
n 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:
Part 1. Grasp the qualities behind an ideal persistence layer
Part 2. Sun JDO vs. Castor JDO
Sun JDO
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.
Architecture
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:
JDO instance
First-class objects
Second-class objects
JDO instance
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.
First-class objects
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 PersistentManager s might manage other instances of that same class.
Second-class objects
Also 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.
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):
Simplicity
Minimal intrusion
Transparency
Consistent, concise persistence APIs
The Sun JDO's major advantage: it provides a unified, standard persistence interface supported by multiple vendors delivering competing implementations. Another advantage is its transparency, or its data-store type independence.
The Sun JDO almost fulfils the simplicity trait, the only offending part being the OQL Query specification, which could be simplified. Sun also fails to offer minimal intrusion. In addition, Sun's JDO could do without the class enhancer or the obligatory PersistenceCapable interface.
Some designed-by-committee traits are also evident: The API is not always consistent. Also, specification development progresses slowly; Sun JDO has been in draft form for several months now.
Overall, however, its standard persistence interface and transparency really set the tone for the Sun JDO. Its future looks quite bright.
Castor JDO
Castor is an open source data-binding framework for Java. Castor's multiple projects target mapping between Java objects, XML documents, SQL tables, and LDAP (lightweight directory access protocol) directories. The Castor JDO project focuses on the Java object persistence-to-relational data stores. Despite its name and resemblance, Castor JDO is not compatible with Sun's spec. Note: Because Castor JDO concentrates on relational data stores exclusively, it does not support data-storage type transparency. Among the nonproprietary API (open source or multivendor) solutions available,
Read
Tutorial at: Click here to view the tutorial
Rate Tutorial: Comparison between the two major JDO architectures
View Tutorial: Comparison between the two major JDO architectures
Related
Tutorials:
 Results of
first-ever JVM server benchmark revealed - JavaWorld - December 1997
Results of
first-ever JVM server benchmark revealed - JavaWorld - December 1997
|
The battle of the container
frameworks: which should you use? - JavaWorld - January
1999
The battle of the container
frameworks: which should you use? - JavaWorld - January
1999
|
Messaging helps move Java into the
enterprise - JavaWorld January 1999
Messaging helps move Java into the
enterprise - JavaWorld January 1999
|
The state of Java application middleware,
Part 1 - JavaWorld March 1999
The state of Java application middleware,
Part 1 - JavaWorld March 1999
|
One, two, three,
or n tiers? - JavaWorld January 2000
One, two, three,
or n tiers? - JavaWorld January 2000
|
C# : A language alternative or just J--? (part1)
C# : A language alternative or just J--? (part1)
|
Double-checked
locking: Clever, but broken - JavaWorld February
2001
Double-checked
locking: Clever, but broken - JavaWorld February
2001
|
Step into
the J2EE architecture and process
Step into
the J2EE architecture and process
|
Java scripting languages: Which is
right for you?
Java scripting languages: Which is
right for you?
|
Good
introduction to JDO
Good
introduction to JDO
|
Comparison between the two major JDO architectures
Comparison between the two major JDO architectures
|
Update distributed applications
Update distributed applications
|
Let the mobile
games begin, Part 2
Let the mobile
games begin, Part 2
|
Object-relation mapping without the container
If you follow the latest developer buzz then you\\\\\'ve likely heard of IOC (Inversion of Control) containers and AOP (aspect-oriented programming).
|
JPOX Java Persistent Objects JDO
Presenting JPOX
With a versatile and high performance implementation, JPOX is on the cutting edge of the available Java Data Objects (JDO) implementations, offering a free and full compliant JDO implementation released under an open source license.
|
Core Java Data Objects Excerpt
This book excerpt is from Core Java Data Objects,
|
Integrate COM and Java components
Interoperability issues have long made integration of Microsoft® Component Object Model (COM) and Java™ components a daunting task. The Development Tool for Java-COM Bridge, available from IBM alphaWorks, simplifies the job and also provides an evoluti
|
Producing Enterprise Architecture:
A Conversation with Sun's Dan Hushon, Part Two In the final part of a two-part interview, Sun Microsystems' Dan Hushon talks about adaptive enterprise architectures, the market for developers, Java Centers of Excellence, and loosely coupled components.
|
Porting Device Drivers for the Solaris Operating System to 64-Bit x86 Architectures
If you need to modify 32-bit device drivers to be compatible with the 64-bit Solaris 10 OS on x86 platforms, refer to this new article.
|
What is Persistence Framework?
What is Persistence Framework?
What is Persistence Framework?
A persistence framework moves the program data in its most natural form (in memory objects) to and from a permanent data store the database. The persistence framework manages the
|
|
|
|
