JDO: Transparent Persistence of Java Objects

P Sivakumar

JDO helps you access information in a data store (e.g. relational database, object database) as Java objects so you can manipulate the data directly using the Java language rather than using database-specific interfaces. The major goal is to provide a standard interface between application objects and data stores — e.g. databases and files

What is JDO:

Java Data Objects (JDO) defines interfaces and classes to be used by the application programmers when using classes whose instances are to be stored in persistent storage (Persistent-capable classes).

Nowadays most of the application requires some sort of data persistence, whether local, remote or both. Developers have to build applications with a specific data store, using some store-specific API like JDBC API. When your existing application accesses those API to query an external data source, the resulting data is fed back to and processed in your application in the form of strings or simple data types, such as 'int'. You have to have knowledge about the external data source and write code to manage the process of accessing and manipulating that external data. This becomes too hard while accessing a numerous persistence data stores.

By defining a set of Java API, JDO provides a unified approach to data access by supporting the construct of a business object persistence manager. This automates mapping between persistent data objects and information in external data stores. Hence developer need not worry, how the data is physically represented. JDO provides developers with another layer of abstraction that encapsulates data store-specific details, letting application programmers’ concentrate on business logic rather than persistence storage intricacies. JDO provides a Java object interface to the data source, so developers perform data operations the same way they treat any other Java object. The result is faster application development (read quicker time to market) and fewer worries about persistent data storage.

Advantages of JDO

• Code is written in Java

• No Need to learn specific access methods like SQL and all. B'caz JDO manage object creation, deletion, retrieve. So coding is simple and bugs can be reduced in numbers in your application.


• Easy to deploy, to configure an application. B'caz JDO automatically manages the mapping between objects during execution with external data.


• Consistent Persistent methods.


• Complex Object Relationship supports.


• Object Orient Approach to data inclusion.

Disadvantages

• New to Industry. Not widely implemented

Figure 1: A typical JDO-based application scenario

This Figure shows the typical JDO-based application scenario.

JDO with Other Technologies

According to Sun Microsystems, JDO will not be included in the next version of J2EE.

Currently, there are two Java standards for storing Java Data Persistently: Serialization and JDBC. Serialization preserves relationships among a graph of Java Objects, but does not support sharing among multiple users. JDBC requires the user to explicitly manage the values of fields and map them into relational database tables. JDO does the both.

We Just look at some differences between JDO and Serialization:

• Serialization doesn't support queries while JDO supports them.


• When it comes to lazy initialization, serialization will only retrieve an entire object graph. JDO allows instantiation of objects as required


• Serialization and deserialization either succeed or fail. JDO supports transactions, in which changes applied to the data store in a transaction either succeed or fail, while other simultaneous transactions independently succeed or fail.


• Serialization does not support remote storage of data, except as transparently done via remote file servers (e.g. NFS). JDO supports remote storage, via the URL pattern. 'siva://host:port/path' refers to a remote JDO server on the specified host and port, using the relative path name specified


• Serialization is built-in to every JVM. JDO is plug gable, allowing different JDO vendors to be used to store objects, at the user's choice


• Both Serialization and JDO will automatically store the closure of an object graph once one of the instances is identified as persistent. Both Serialization and JDO store the entire object graph as one file.


• Serialization will retrieve an entire object graph with one call, with no option on how many objects to retrieve. JDO allows retrieval of a single object at a time


• Serialization does not support updates to serialized object graphs. JDO supports updates to object graphs. If any change is made to the object graph, only the changed objects are stored in the file.

Take the other one of JDBC

• JDO is an API for transparent database access which negates the need to write database-specific code (such as SQL) in applications.


• Universal persistence. While JDBC is limited to RDBMS, JDO is potentially able to cope with any kind of data source, including RDBMS, ODBMS, TP Monitors Transactions, ASCII flat files, XML files, Properties files, COBOL databases on mainframes,… JDO is clear solution for large of heterogeneous data sources.

Many developers want to know if JDO replaces JDBC. That's wrong. The two technologies are meant to complement each other. JDO makes simply of accessing data and manipulation without SQL. But JDBC gives direct control to developers over database access. And also widely used one.

And also, JDO might be used in persistent helper classes for session beans, as delegate classes for BMP entity beans, or for delegate classes for CMP Entity Beans.

The API and a simple example:

The JDO standard makes possible the direct expression of a domain object model to standard persistence services.

An application object is persisted by a statement such as

persistenceManager.makePersistent(applicationObject); and then only when the need for persistence must be explicitly stated.

When a reference to a persistent object is available, the persistent objects it has persistent references to are available for use without any application programming for database activity. It appears that entire object graph is in the JVM, rather like a virtual address space giving the appearance that everything is in RAM.

There is no application use of a data manipulation language.

The Java Data Objects specification was developed under by JSR 12 http://www.jcp.org/en/jsr/detail?id=12

In the JDO API, there are six interfaces, two classes and nine exceptions. These counts are quite low for an API. It will become rare that you have to lookup a method in the javadoc.

The interfaces are:PersistenceManagerFactory; PersistenceManager; Transaction;

InstanceCallbacks; Extent; Query.

The classes are:

JDOHelper; I18NHelper.

Here is sample code for standalone JDO:

PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory(properties);

PersistenceManager pm = pmf.getPersistenceManager();

Transaction transaction = pm.currentTransaction();

transaction.begin();

pm.makePersistent(appObj1);

pm.makePersistent(appObj2);

pm.makePersistent(appObj3);

transaction.commit();

persistenceManager.close();

A PersistenceManager has at most one active transaction. A PersistenceManager’s transaction can be sequentially reused.

JDO Query Language:

JDOQL enables you to dynamically build and execute complex queries using Java-like syntaxes. JDO has its own Query Language, called JDOQL. Queries are very Java-like in syntax, which makes JDOQL very easy for java developers to learn and use. JDOQL is entirely portable across all JDO implementations, so there will be no portability issues from JDOQL 'dialects' as there is with SQL.

There are few things that JDOQL cannot do yet, such as aggregate functions and projection. There are already being discussed for inclusion in JDO version 2.0.

JDO holds the promise of simplifying data access by removing much of the drudgery developers currently endure to interact with data sources in Java applications. No other technology available offers a comparable combination of portability, power, and simplicity. Then waiting for what?

P. Sivakumar

Senior Consultant

Object Frontier Software Pvt Ltd.,

Chennai.

Feel free to write to me @ sivakumarp@object-frontier.com

 

About me:

I’m an M.C.A Professional and having more than 4 ½ yrs of exp in J2EE Technologies. Working as a Senior Consultant in Object Frontier Software Pvt Ltd., Chennai.