The JDO Persistence Model

Seminar Paper, 2005

9 Pages, Grade: 1,3

Free online reading


JDO is a specification for design object domain models without having to consider the persistency of data. The main target of JDO is the abstraction of concrete data storage solutions and the provision of transparent and implementation-independent solutions for persistent data.

Starting with an introduction to the architectural model of Java Data Objects, benefits of this approach and the realization by a tool-based enhancement are outlined. Furthermore, the API itself is in focus of examination, main programming interfaces and the JDO-QL will be discussed.

Finally, it is aimed to give an outlook on the up­coming JDO 2.0 specification.

Keywords: Java, Persistence, JDO, Database,

Code Enhancement

1. Introduction

Persistence of data is one of the main require­ments of business application software. Relational databases are the most commonly used systems to meet these requirements. They are wide spread and highly optimized for performance and reli­ability. However, the use of RDBMS requires mapping of business object models to a specific database schema and introduces complexity and dependencies into the development process and the resulting product. This leads to a reduced exchangeability of the used data storage which delimitates the reusability and spectrum of appli­cations.

So, an effort should be the introduction of a standardized abstraction layer. This entails inde­pendence of a specific data storage type, disposes the necessity of mapping your object model on a data schema, and reduces the modeling and pro­gramming complexity for persistence itself.

2. JDO

2.1. What is JDO?

The Java Data Objects (JDO) API is a standard interface-based definition of object persistence. It describes the transparent storage and retrieval of Java objects.

JDO is intended to provide transparent mechanisms to persist the whole object domain model of an application, including mapping of JDO instances to data storage and implicit updates of persistent object states.

It is intended to reduce most efforts of introducing a persis­tence layer by the use of automated en­hancements.

illustration not visible in this excerpt

Figure 1 is a sim­plified example of a typical application using JDO as persis­tence service. The [JDOSPEC] requires all JDO implementa­tions to be binary compatible. Thereby, it is possible to ex­change a specific JDO implementation and start to use another type of datastore without the need to recompile the whole application.

A JDO implementation, delivered by a third- party vendor is highly optimized on a particular data storage system like common RDBMS, ODBMS, or maybe XML-based file storage de­pending on the area of application. The intro­duced abstraction layer results in an application which is independent of a single data storage type and could be used with a variety of different kinds of these systems.

illustration not visible in this excerpt

Figure 3.1 Persistence without and with JDO

illustration not visible in this excerpt

Figure 3.2 Persistence with JDO

2.2. Advantages of using JDO

In Figure 2 a FMC based block diagram is in­tended to visualize the different modeling efforts. Figure 2.1 illustrates an application, which uses a relational database system for persistence and services implementing class specific persistence methods. Figure 2.2 displays an application using JDO for data persistence.

The system on the left hand side consists of a generic persistency manager which implements the main functionality and a number of class spe­cific persistence managers which realize the data storage and retrieval for the class specific attrib­utes based on a mapping between attributes and rows in a database schema. For each class in the object domain model a specific persistence man­ager is necessary. In addition, a transaction service has to be implemented which might be provided by a used persistence framework, but in general it is a service tailored to a specific generic persistence manager.

Figure 2.2 displays the Java Data Objects way. Most functionality is realized by the JDO imple­mentation. The transaction service is part of the specification and class persistence is implemented by transparent techniques. There is no program­ming or modeling effort to get these functional­ities. The operations like creating, finding, modifying, or storing persistent objects are cov­ered by the JDO API. Initial operations like make an object persistent or delete it from the data store are realized by the JDO PersistenceManager inter­face. A small introduction to the main interfaces is given in a later section of this paper.

This architecture results in a storage-type in­dependent object model and provides access to persistent data objects without knowledge of internal mapping or data store specific query languages.

2.3. Environments for JDO

JDO is intended to be used in two types of envi­ronments, non-managed and managed environ­ments.

In a non-managed environment the applica­tion is directly connect to resources it needs and it is responsible for invocation of persistence actions on objects or configuration of connections to re­sources. In such environments the programmer and application are independent of e.g. J2EE con­tainer technologies but have to handle all interac­tions with the underlying persistence service.

In contrast to this, managed environments like J2EE-based multi-tier applications provide, in conjunction with the used container, special mechanisms for declarative configuration of the persistence service in use.

Depending on the used container, the con­tainer itself takes responsibility for configuring the service, managing transactions, providing security services, or pooling of PersistenceMan- agers.

The JDO transactions are harmonized with J2EE transactions. It is up to the programmer to
decide, which type of transaction will be used. JDO implementations can synchronize there transaction to distributed J2EE transactions. Stan­dards like EJB, JSP, Servlets, CMT, and BMT are supported and JDO is designed to be used in such environments.

2.4. The Class Enhancement

The benefits in modeling and programming are achieved by an automated enhancement process. The JDO specification requires every JDO imple­mentation to provide an enhancer tool, which is binary compatible to the standard. This enhancer tool wiil work on Java Bytecode files, the class files.

The structure and an example are shown in Figure 3. The developer will design a class accord­ing to domain requirements like an order for multiple items with a given date. This order should be persisted in a database with all associ­ated items. Therefore, no changes have to be made on the domain model, neither by changes on attribute visibility nor by adding special per­sistence methods and attributes.

All necessary changes for realizing persistence will be added by the enhancer and do not influ­ence the Java object model. The developer has to create an XML-file which names and describes the classes to be persisted. Depending on the used JDO implementation, there are several vendor- specific extensions to the XML-file possible. In some cases it is necessary to build a new applica­tion upon an existing database structure and the developer will have to map his class attributes on a database schema. Furthermore, the specification provides additional settings for persistent fields. It is possible to control the persistence behavior in more detail. Especially for collections and arrays handling and type of included objects has to be specified. In addition, the object identity type can be specified. For all unspecified details default settings are used.

After creating the JDO Metadata the developer can initiate the enhancement process. According to the named classes, the JDO Enhancer will mod­ify the Java Bytecode. It will implement the Persis- tenceCapable interface and add several methods and fields to the classes. On the right side of

illustration not visible in this excerpt

Figure 4 Enhancement and its effects

Figure 3 a couple of effects on data classes are outlined.

For each persistent attribute a set of getter and setter methods will be added and executable code, which accesses the attribute, will be changed to call the accessor or mutator methods. With these changes, the added StateManager is able to guarantee data persistence for all modifi­cations on a single data object.

Even if it is possible to implement the Persis- tenceCapable interface manually it is strongly rec­ommended not to do so. No methods and attributes with the prefix jdo should be used di­rectly in unenhanced code. Most tasks can be done by using the JDOHelper class instead of calling these methods and attributes.

It is important to know that JDO Metadata will be used by the enhancer tool to identify classes to be made persistence capable, and some informa­tion like mapping rules or other vendor-specific enhancements are used at runtime. Therefore, behavior is not specified if the metadata is changed after initiating the enhancement process.

3. Using JDO

This part aims to give a short introduction into the main classes and interfaces a JDO program­mer has to concern with. Furthermore, the used concepts for object identity, object lifecycle, and the JDO-Query Language are outlined. The rela­tionships between main interfaces are illustrated in Figure 4.

illustration not visible in this excerpt

Figure 5 Main JDO Interfaces

3.1. The Persistence Manager

The main interface for application developers is the PersistenceManager interface. It is intended to be used for all persistence operations on Persis- tenceCapable1 objects and provides overloaded variants of most cache management and instance lifecycle methods. These methods manipulate single instances, collections, arrays of instances, or potentially all applicable instances in the cache. Besides, it is used to obtain Query, Extent, and Transaction objects.

Depending on the environment, there are sev­eral ways to retrieve such a manager object. In non-managed environments the concrete class JDOHelper makes the PersistenceManagerFactory available.

A PersistenceManagerFactory object is used to get an instance of PersistenceManager. Thereby, it is possible to get more than one PersistenceMan- ager object from a single factory. The factory can even implement pooling.

In J2EE environments, it is possible to obtain a factory from properly configured JNDI (Java Naming and Directory Interface).

After obtaining a PersistenceManager object the following methods can be used by an application:

- makePersistent(...)

These methods can be used to explicitly make transient objects persistent so they will be stored in the datastore after the transaction completes successfully. They can only be used within a transaction, otherwise a JDOUserException is thrown.

In fact, applications rarely need to invoke makePersistent() directly. Usually, newly created objects are referenced by existing persistent objects, e.g. via a singleton reference or membership of a collection. In such cases, the new object will be transparently made persistent when the transaction is committed.

- deletePersistent(...)

These methods delete persistent instances from the database and must be called in the context of an active transaction. The Java object thus remains, but no longer represents the persistent data store entity, which has been deleted. Unlike making objects persistent, deleting objects only deletes the specified instances. There is no reach-ability algorithm; referenced persistent objects are not deleted.

To emulate this behavior, the InstanceCallbacks can be used to implement the jdoPreDelete() method to delete referred objects.

- makeTransient(...)

Make a persistent instance transient again. This does not affect the underlying data store entity in any way. It does not delete the data. The instance will be disassociated from the datastore only, and any subsequent changes to the instance will not be synchronized with the datastore.

- evict(...) or evictAll()

Evict the given or all cached persistence- capable instances from the cache. However, eviction is only a hint to the persistence manager that an instance should be removed from its cache. By default persisted objects are automatically evicted, and it is not necessary for an application to do it programmatically.

- refresh(...)

These methods re-retrieve the values of the fields from the datastore for the specified instances, whether or not they have been already modified in the current transaction.

Furthermore, there are additional methods which will be discussed in more detail e.g. in [JDOAW2003] and [JDOPH2003].

3.2. Transactions

A transaction is a group of modifications on per­sistent objects; these modifications must be com­pleted in its entirety or not at all. The demands for ACID (Atomic, Consistent, Isolated, Durable) have to be met.

Most resource managers allow different levels of isolation. Nevertheless, developers should not rely on any isolation level greater than Read Committed, because JDO does not explicitly spec­ify the isolation level that will be applied.

On isolation level of Read Committed, state changes of persisted objects within a transaction cannot be seen by other transactions until a com­mit has been issued.

Per PersistenceManager, only a single transac­tion is possible at a time. Furthermore, JDO does not support the concept of nested transactions.

To work with concurrent transactions addi­tional PersistenceManager instances are required, which may be provided by pooling via Persis- tenceManagerFactory or via methods in a J2EE environment.

JDO supports two transaction strategies. Pes­simistic transactions are a required feature, whereas optimistic transactions are an optional feature.

Therefore, pessimistic transactions are the de­fault. They are suitable for short-living transac­tions. Typically, there is no user interaction or other blocking operations between start and end of a transaction. This type of transaction will ex­clude other transactions from accessing data, which is accessed within.

When working with long-living transactions, it is often unacceptable to deny access on data used within this transaction, the complete period of time the transaction lasts. To reduce such data locking, optimistic transaction will not lock the accessed data. They may be implemented with native optimistic transactions of the underlying datastore or they are implemented using two pessimistic transactions.

The first pessimistic transaction is used to get the current state of used data objects from the data storage. This state will be saved for later data integrity checks.

After doing all modifications on the persistent objects over a longer period of time, the second pessimistic transaction is started. This one will retrieve the actual state from the datastore and compare it with the saved data. If the data integ­rity is ensured, all operations done on the data objects will be committed. If a concurrent opera­tion has changed the data in the datastore, the whole optimistic transaction will fail and an ex­ception will be thrown.

A transaction object can be obtained from the PersistenceManager by invocation of currentTrans- action(). With begin() and commit() a demarcation of actions belonging to a transaction is done. roll- back() is used to discard modifications on persis­tent objects in an erroneous transaction.

3.3. Object Identities

JDO provides three different kinds of identity for persisted objects. This is done to improve the transparency and the mechanisms provided by Java for identity (==) and equality (equals()) re­main unaffected.

The default type of object identity is called Datastore Identity. A unique Identity is assigned to an object when it is made persistent. The nature of this Object-ID is handled internal by the JDO implementation and the underlying data store. Theoretically datastore identity corresponds to primary-keys in RDBS.

Application Identity is the second and most complex type of object identity. It is used, if the object identity is derived from a subset of persis­tent fields of an object or created outside of the application, like ISBN.

For this type of identity, it is necessary to im­plement a specific Object-ID class, which fulfils special requirements. The Object-ID class has to implement the interface and the toString(), equals(), and hashCode() methods have to be overridden. All requirements are listed in section 5.4.1 of the [JDOSPEC].

The third, non-durable identity is used for ob­jects without need for own identity, like simple lists or bulk data.

3.4. Object Lifecycle

JDO defines a number of states for persistent objects. These states are used by the JDO runtime to manage the in-memory lifecycle of persistent objects and to decide when data has to be syn­chronized with data store. Not all states are re­quired by the specification. For instance Persistent- Nontransactional, Transient-Clean, and Transient- Dirty are optional states and are only required if a specific JDO implementation provides associated optional features.

In this section, only required states and state transitions are treated, which are also shown in Figure 5.

3.4.1. Transient

JDO does not influence standard object construc­tion mechanisms in conjunction with the new operator. Therefore, all objects created with a developer-written constructor are transient by default. They behave like instances of the un­enhanced class. Until they are made persistent, there is no identity associated with these objects. Moreover, there is no handling of persistent fields and no transactional behavior.

If a transient object of an enhanced class is re­ferred by a persistent object at commit time, it will be persisted.

3.4.2. Persistent-New

Instances are in this state if they have been made persistent during the current transaction. During the transition from transient to persistent, the associated PersistenceManager becomes responsi­ble for handling further state transitions, handling of field values for rollbacks, and synchronization with data store. Furthermore, it will assign a JDO identity to the instance.

illustration not visible in this excerpt

3.4.3. Persistent-New-Deleted

This state will be reached if an object has made persistent and be deleted within one single trans­action.

3.4.4. Hollow

Objects in the Hollow state are already persisted, but at this state only their object identity is loaded. All ordinary attribute values have not been loaded.

3.4.5. Persistent-Clean

The data of these objects had been read, but not modified within the current transaction.

3.4.6. Persistent-Dirty

The data of objects in this state had been changed in the current transaction, or the makeDirty() method of JDOHelper had been invoked.

A call to makeDirty() is useful, when changes to a persistent field of an array type had been made, since JDO does not require automatic tracking of changes made to array fields.

3.4.7. Persistent-Deleted

JDO instances that have been deleted in the cur­rent transaction are Persistent-Deleted.

3.5. Extents

An Extent represents the complete set of all per­sistent instances of a class. It is obtained from a PersistenceManager by getExtent and it is possible to decide whether items of subclasses should be included or excluded.

The primary purpose of an extent is to provide a candidate collection of objects to be used in a query, where filtering or ordering can be applied.

Nevertheless, it can be used to access all per­sisted objects of a given class and maybe its sub­classes, therefore an Iterator is provided by the Extent interface.

The data-retrieval process will not start until the first invocation of next() on a obtained Iterator. Thus, it is possible to delegate an Extent to a Query without unnecessary data access.

3.6. JDO-Query Language

The aim of the JDO-Query Language is to provide a simple query grammar that is familiar to Java programmers and that can be executed by the

JDO implementation, possibly by converting it to a different representation and passing it to the underlying data store. Hence, it abstracts from data store languages like SQL or other datastore depending premises.

JDO enables vendor-specific enhancements and additional query languages. In some imple­mentations it is possible to use SQL query state­ments concurrent to native JDO-QL queries.

A query itself consists of a set of candidate in­stances, which can be specified using a Java class, an Extent, or a collection and a filter string. In addition it is also possible to declare import state­ments, parameters and variables as well as an ordering for the set of results. When executed, a query takes the set of candidate instances and returns a Java collection of references to the in­stances that satisfies the query filter.

Queries will be highly optimized on the un­derlying datastore, depending on the JDO imple­mentation. For instance, Extents can internally be used to produce an equivalent query in native data store language.

Filter strings of JDO-QL can consist of attribute names, logical operators, references on objects and a few methods related to strings or objects.

For instance, a filter string can be 'attrName == \"string\"'. A few common supported logical operators are !, &&, ||, <, >, ==, etc. Indeed, for string comparison no SQL like like-operator is supported. JDO provides startsWith() and endsWith() constraints. To assists work with col­lections of objects, isEmpty() and contains(Object o) are specified.

In comparison with SQL or other common query languages JDO-QL is limited to the very basics in version 1.0.1, but will be enhanced in the upcoming JDO 2.0 standard.

4. Outlook on JDO 2.0

The upcoming revision of JDO, so called JDO 2.0, is finally approved. It will provide several im­provements to the first version of Java Data Ob­jects.

In particular, JDO 2.0 implementations will be binary compatible to all earlier versions and among each other. Nevertheless, it will introduce new interesting additional features.

One of the main targets had been to specify a standard object/relational mapping to improve JDO's acceptance among the general program­ming public. Standardized mapping and runtime behavior will improve portability between differ­ent JDO implementations and will increase utility of vendor independent tools.1

Furthermore, JDO 2.0 will introduce an at­tach/detach API, which will simplify handling objects in multi-tier applications. For instance, an application has to transfer an object to a client and allow the client to modify its states. Afterwards, the object has to be returned and the modifica­tions done have to be saved.

Maybe, the most important improvements had been done on the JDO-Query Language. Its capa­bilities had been enhanced a lot, compared to JDO 1.0. The JDO-QL will now support aggregates, named queries, projections and additional func­tions for string-related and mathematic opera­tions.

In JDO 1.0 all query results had been a collec­tion of objects identified by the query. Since addi­tion of projections and aggregates in JDO 2.0 a result can be an array of objects, which represents a table of records with named columns.

The newly supported aggregate functions are count(), sum(), avg(), min(), and max(). The follow­ing functions had been introduced to enhance string and math capabilities:

- get(Object) applies to Map types
- containsKey(Object) applies to Map types
- containsValue(Object) applies to Map types
- toLowerCase() applies to String type
- toUpperCase() applies to String type
- indexOf(String) applies to String type
- matches(String) applies to String type, but only the following regular expression patterns are required to be supported: Global "(?i)" for case­insensitive matches; and "." and ".*" for wild card matches.
- substring(int, int) applies to String type
- Math.abs(numeric)
- Math.sqrt(numeric)
- JDOHelper.getObjectId(Object) static method in JDOHelper, allows using the object identity of an instance directly in a query.

5. Conclusion

Persistence is one of the most important concepts in business applications. Therefore, an easy to use and common interface is required to meet busi­ness requirements.

JDO will meet these requirements in most cases. It is a standardized interface-based defini­tion of object persistence, which is supported by leading vendors.

Provided transparency will help to reduce modeling and programming efforts, compared to ordinary JDBC and SQL usage, which neverthe­less is not obsolete in specific use cases. Further­more, the abstraction of specific data storage will lead to an improved portability of the whole ap­plication.

The programmer itself will benefit in an API for accessing persistent data with object model information only and tools which provide this transparency by automated code enhancement.

While JDO 1.0 may not suit anyone, JDO 2.0 will bring a lot of promising improvements and may be considered when choosing a persistence framework.


[JDOSPEC] Java Data Objects Specification /jsr012/index2.html

[JDO20DRAFT] Java Data Objects 2.0 Public Draft sr243/index2.html·

[FMC] Fundamental Modeling Concepts

[JDOC] JDO Java Doc

[UUJDO2003] David Ezzio, Using and Understanding Java Data Objects, Apress, 2003

[JDOPH2003] Sameer Tyagi et al. Core Java Data Objects, Prentice Hall PTR, 2003

[JDOAW2003] Robin M. Roos, Java Data Objects, Addison Wesley, 2003

[JDOO2003] David Jordan and Craig Russell, Java Data Objects, O'Reilly, 2003

[HOLU2004] Andreas Holubek, Java Data Objects in der Praxis, Javamagazin 06/2004


1 In 2.4 the enhancement process is outlined which adds the PersistenceCapable interface to all class meant to be made per­sistent.

2 E.g. Versant offers an Eclipse plug-in for JDO based devel­opment as open source software en-us

9 of 9 pages


The JDO Persistence Model
University of Potsdam
Seminar Systemmodeling
Catalog Number
ISBN (Book)
File size
705 KB
Persistence, Model, Seminar, Systemmodeling
Quote paper
Stefan Marr (Author), 2005, The JDO Persistence Model, Munich, GRIN Verlag,


  • No comments yet.
Read the ebook
Title: The JDO Persistence Model

Upload papers

Your term paper / thesis:

- Publication as eBook and book
- High royalties for the sales
- Completely free - with ISBN
- It only takes five minutes
- Every paper finds readers

Publish now - it's free