The Java Data Objects Persistence Model

Abstract

2. JDO

JDO is a specification for design object domain models

without having to consider the persistency of data. The

2.1. What is JDO?

main target of JDO is the abstraction of concrete data storage solutions and the provision of transparent and The Java Data Objects (JDO) API is a standard implementation-independent solutions for persistent interface-based definition of object persistence. It data.

describes the transparent storage and retrieval of Starting with an introduction to the architectural Java objects.

model of Java Data Objects, benefits of this approach

JDO is intended to provide transparent

and the realization by a tool-based enhancement are mechanisms to persist the whole object domain outlined. Furthermore, the API itself is in focus of model of an application, including mapping of examination, main programming interfaces and the

JDO instances to data

JDO-QL will be discussed.

coming JDO 2.0 specification.

Keywords: Java, Persistence, JDO, Database,

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 change a specific JDO implementation and start to delimitates the reusability and spectrum of appli- use another type of datastore without the need to cations.

recompile the whole application.

So, an effort should be the introduction of a

A JDO implementation, delivered by a third-

standardized abstraction layer. This entails inde- party vendor is highly optimized on a particular pendence of a specific data storage type, disposes data storage system like common RDBMS, the necessity of mapping your object model on a ODBMS, or maybe XML-based file storage de- data schema, and reduces the modeling and pro- pending on the area of application. The intro- gramming complexity for persistence itself.

duced abstraction layer results in an application

an object persistent or delete it from the data store which is independent of a single data storage type are realized by the JDO PersistenceManager inter- and could be used with a variety of different face. A small introduction to the main interfaces is kinds of these systems.

given in a later section of this paper.

2.2. Advantages of using JDO

This architecture results in a storage-type in- dependent object model and provides access to In Figure 2 a FMC based block diagram is in- persistent data objects without knowledge of tended to visualize the different modeling efforts. internal mapping or data store specific query Figure 2.1 illustrates an application, which uses a languages.

relational database system for persistence and services implementing class specific persistence

2.3. Environments for JDO

methods. Figure 2.2 displays an application using

JDO for data persistence.

JDO is intended to be used in two types of envi-

ronments, non-managed and managed environ- The system on the left hand side consists of a ments.

generic persistency manager which implements the main functionality and a number of class spe- In a non-managed environment the applica- cific persistence managers which realize the data tion is directly connect to resources it needs and it storage and retrieval for the class specific attrib- is responsible for invocation of persistence actions utes based on a mapping between attributes and on objects or configuration of connections to re- rows in a database schema. For each class in the sources. In such environments the programmer object domain model a specific persistence man- and application are independent of e.g. J2EE con- ager is necessary. In addition, a transaction service tainer technologies but have to handle all interac- has to be implemented which might be provided tions with the underlying persistence service. by a used persistence framework, but in general it In contrast to this, managed environments like is a service tailored to a specific generic persistence J2EE-based multi-tier applications provide, in manager.

conjunction with the used container, special mechanisms for declarative configuration of the Figure 2.2 displays the Java Data Objects way. persistence service in use.

Most functionality is realized by the JDO imple- mentation. The transaction service is part of the Depending on the used container, the con- specification and class persistence is implemented tainer itself takes responsibility for configuring by transparent techniques. There is no program- the service, managing transactions, providing ming or modeling effort to get these functional- security services, or pooling of PersistenceMan- ities. The operations like creating, finding, agers.

modifying, or storing persistent objects are cov- The JDO transactions are harmonized with ered by the JDO API. Initial operations like make J2EE transactions. It is up to the programmer to

All necessary changes for realizing persistence tence decide, which type of transaction will be used.

ll be added by the enhancer and do not influ- wi wi

JDO implementations can synchronize there

ll be added by the enhancer and do not influ-

ence the Java object model. The developer has to transaction to distributed J2EE transactions. Stan- ence the Java object model. The developer has to

create an XML-file which names and describes the dards like EJB, JSP, Servlets, CMT, and BMT are create an XML-file which names and describes the

classes to be persisted. Depending on the used supported and JDO is designed to be used in such classes to be persisted. Depending on the used

JDO implementation, there are several vendor-

environments.

JDO implementation, there are several vendor-

specific extensions to the XML-file possible. In specific extensions to the XML-file possible. In

2.4. The Class Enhancement

some cases it is necessary to build a new applica- some cases it is necessary to build a new applica-

tion upon an existing database structure and the tion upon an existing database structure and the

The benefits in modeling and programming are

developer will have to map his class attributes on developer will have to map his class attributes on

achieved by an automated enhancement process.

a database schema. Furthermore, the specification a database schema. Furthermore, the specification

The JDO specification requires every JDO imple-

provides additional settings for persistent fields. provides additional settings for persistent fields.

mentation to provide an enhancer tool, which is

It is possible to control the persistence behavior in It is possible to control the persistence behavior in

binary compatible to the standard. This enhancer

more detail. Especially for collections and arrays more detail. Especially for collections and arrays

tool will work on Java Bytecode files, the class

handling and type of included objects has to be handling and type of included objects has to be

files.

specified. In addition, the object identity type can specified. In addition, the object identity type can

The structure and an example are shown in

be specified. For all unspecified details default be specified. For all unspecified details default

Figure 3. The developer will design a class accord-

settings are used.

settings are used.

ing to domain requirements like an order for

After creating t

After creating t he JDO Metadata the developer he JDO Metadata the developer

multiple items with a given date. This order

can

initiate the enhancement process. According can initiate the enhancement process. According

should be persisted in a database with all associ-

to the named classes, the JDO Enhancer will mod- to the named classes, the JDO Enhancer will mod-

ated items. Therefore, no changes have to be

ify the Java Bytecode. It will implement the Persis- ify the Java Bytecode. It will implement the Persis-

made on the domain model, neither by changes

tenceCapable interface and add several methods tenceCapable interface and add several methods

on attribute visibility nor by adding special per-

and fields to the classes. On the right side of and fields to the classes. On the right side of

sistence methods and attributes.

tenceCapable 1 objects and provides overloaded

Figure 3 a couple of effects on data classes are outlined. variants of most cache management and instance For each persistent attribute a set of getter and lifecycle methods. These methods manipulate

single instances, collections, arrays of instances, or

set

ter methods will be added and executable potentially all applicable instances in the cache.

code, which accesses the attribute, will be Besides, it is used to obtain Query, Extent, and

changed to call the accessor or mutator methods. Transaction objects.

With these changes, the added StateManager is Depending on th

able to guarantee data persistence for all modifi-

e environment, there are sev-

cations on a single data object.

Even if it is possible to imp

ten JDOHelper makes the PersistenceManagerFactory

ceCapable interface manually it is strongly rec- available.

ommended not to do so. No methods and

A Persi

attributes with the prefix jdo should be used di-

stenceManagerFactory object is used to rectly in unenhanced code. Most tasks can be

get

an instance of PersistenceManager. Thereby, it done by using the JDOHelper class instead of

is possible to get more than one PersistenceMan- calling these methods and attributes.

ager object from a single factory. The factory can It is important to know that JDO M

even implement pooling.

etadata will

In J2EE environments,

be

it is possible to obtain a

used by the enhancer tool to identify classes to fac

be made persistence capable, and some informa-

tory from properly configured JNDI (Java tion like mapping rules or other vendor-specific

Naming and Directory Interface).

enhancements are used at runtime. Therefore,

nager object the

After obtaining a PersistenceMa behavior is not specified if the metadata is

fol

lowing methods can be used by an application: changed after initiating the enhancement process.

• makePersistent(…) be used to explicitly make

These methods can

3. Using JDO

transient objects persistent so they will be stored in the datastore after the transaction ive a short introduction into This part aims to g d

completes successfully. They can only be use the main classes and interfaces a JDO program- within a transaction, otherwise a mer has to concern with. Furthermore, the used JDOUserException is thrown.

concepts for object identity, object lifecycle, and In fact, applications rarely nee

d to invoke the JDO-Query Language are outlined. The rela- makePersistent() directly. Usually, newly cre

ated tionships between main interfaces are illustrated objects are referenced by existing persistent in Figure 4.

objects, e.g. via a singleton reference or

can be used to implement the jdoPreDelete()

3.1. The Persistence Manager

method to delete referred objects.

evelopers is The main interface for application d 1 In 2.4 the enhancement process is outlined which adds the

the PersistenceManager interface. It is intended to PersistenceCapable interface to all class meant to be made per- be used for all persistence operations on Persis- sistent.

•

feature.

makeTransient(…)

•

•

Fu ich

rthermore, there are additional methods wh

pessimistic transaction is started. This one will will be discussed in more detail e.g. in

retrieve the actual state from the datastore and [JDOAW2003] and [JDOPH2003].

compare it with the saved data. If the data integ- rity is ensured, all operations done on the data

3.2. Transactions

objects will be committed. If a concurrent opera- tion has changed the data in the datastore, the

up of modifications on per- A transaction is a gro

whole optimistic transaction will fail and an ex-

sistent objects; these modifications must be com- ception will be thrown.

pleted in its entirety or not at all. The demands for

A transaction object

can be obtained from the

ACID (Atomic, Consistent, Isolated, Durable)

Per

sistenceManager by invocation of currentTrans-

have to be met.

action(). With begin() and commit() a demarcation

Most resourc

e managers allow different levels

of i

solation. Nevertheless, developers should not back() is used to discard modifications on persis-

rely on any isolation level greater than Read tent objects in an erroneous transaction.

Committed, because JDO does not explicitly spec- ify the isolation level that will be applied.

3.3. Object Identities

On isolation level of Read Committed

, state

changes of persisted objects within a transaction

nt kinds of identity for JDO provides three differe

cannot be seen by other transactions until a com-

persisted objects. This is done to improve the mit has been issued.

transparency and the mechanisms provided by Per PersistenceMan

ager, only a single transac-

tio

n is possible at a time. Furthermore, JDO does not support the concept of nested transactions.

tio

nal PersistenceManager instances are required,

to an object when it is made persistent. The nature which may be provided by pooling via Persis-

of this Object-ID is handled internal by the JDO tenceManagerFactory or via methods in a J2EE

implementation and the underlying data store. environment.

Theoretically datastore identity corresponds to rts two transaction strategies. Pes- JDO suppo

sim

Application Identity

is the second and most whereas optimistic transactions are an optional

In this section, only required states and state com plex type of object identity. It is used, if the

transitions are treated, which are also shown in object identity is derived from a subset of persis-

Figure 5.

tent fields of an object or created outside of the

application, like ISBN.

3.4.1. Transient

For this type of iden tity, it is necessary to im-

ple

ment a specific Object-ID class, which fulfils

JDO does not influence standard object construc-

special requirements. The Object-ID class has to tion mechanisms in conjunction with the new

implement the java.io.Serializable interface and the operator. Therefore, all objects created with a

toString(), equals(), and hashCode() methods have developer-written constructor are transient by

to be overridden. All requirements are listed in default. They behave like instances of the un-

section 5.4.1 of the [JDOSPEC].

enhanced class. Until they are made persistent,

The third, non-durable identity is used for ob-

jec

ts without need for own identity, like simple Moreover, there is no handling of persistent fields

lists or bulk data.

and no transactional behavior.

If a transient object of an enhanced class is re-

3.4. Object Lifecycle

ferred by a persistent object at commit time, it will

be persisted.

of states for persistent JDO defines a number

objects. These states are used by the JDO runtime

3.4.2. Persistent-New

to manage the in-memory lifecycle of persistent Instances are in this state if they have been made objects and to decide when data has to be syn- persistent during the current transaction. During chronized with data store. Not all states are re- the transition from transient to persistent, the quired by the specification. For instance Persistent- associated PersistenceManager becomes responsi- Nontransactional, Transient-Clean, and Transient- ble for handling further state transitions, handling Dirty are optional states and are only required if a of field values for rollbacks, and synchronization specific JDO implementation provides associated with data store. Furthermore, it will assign a JDO optional features.

identity to the instance.

3.4.3. Persistent-New-Deleted

JDO implementation, possibly by converting it to

a different representation and passing it to the

This state will be reached if an object has made underlying data store. Hence, it abstracts from

persistent and be deleted within one single trans- data store languages like SQL or other datastore

action.

depending premises.

JDO enables vendor-specific enhancements

3.4.4. Hollow

and additional query languages. In some imple- Objects in the Hollow state are already persisted,

mentations it is possible to use SQL query state- but at this state only their object identity is

ments concurrent to native JDO-QL queries. loaded. All ordinary attribute values have not

A query itself consists of a set of candidate in-

been loaded.

stances, which can be specified using a Java class, an Extent, or a collection and a filter string. In

3.4.5. Persistent-Clean

addition it is also possible to declare import state- The data of these objects had been read, but not

ments, parameters and variables as well as an modified within the current transaction.

ordering for the set of results. When executed, a query takes the set of candidate instances and

3.4.6. Persistent-Dirty

returns a Java collection of references to the in- The data of objects in this state had been changed

stances that satisfies the query filter.

in the current transaction, or the makeDirty()

Queries will be highly optimized on the un- method of JDOHelper had been invoked.

derlying datastore, depending on the JDO imple-

A call to makeDirty() is useful, when changes to

mentation. For instance, Extents can internally be a persistent field of an array type had been made,

used to produce an equivalent query in native since JDO does not require automatic tracking of

data store language.

changes made to array fields.

Filter strings of JDO-QL can consist of attribute names, logical operators, references on objects

3.4.7. Persistent-Deleted

and a few methods related to strings or objects. For instance, a filter string can be ‘attrName

JDO instances that have been deleted in the cur-

== \"string\"’. A few common supported logical

rent transaction are Persistent-Deleted.

operators are !, &&, ||, <, >, ==, etc. Indeed, for string comparison no SQL like like-operator is

3.5. Extents

supported. JDO provides startsWith() and An Extent represents the complete set of all per-

endsWith() constraints. To assists work with col- sistent instances of a class. It is obtained from a

lections of objects, isEmpty() and contains(Object o) PersistenceManager by getExtent and it is possible

are specified.

to decide whether items of subclasses should be

In comparison with SQL or other common included or excluded.

query languages JDO-QL is limited to the very The primary purpose of an extent is to provide

basics in version 1.0.1, but will be enhanced in the a candidate collection of objects to be used in a

upcoming JDO 2.0 standard.

query, where filtering or ordering can be applied. Nevertheless, it can be used to access all per-

4. Outlook on JDO 2.0

sisted objects of a given class and maybe its sub- classes, therefore an Iterator is provided by the

The upcoming revision of JDO, so called JDO 2.0, Extent interface.

is finally approved. It will provide several im- The data-retrieval process will not start until

provements to the first version of Java Data Ob- the first invocation of next() on a obtained Iterator.

jects.

Thus, it is possible to delegate an Extent to a

In particular, JDO 2.0 implementations will be Query without unnecessary data access.

binary compatible to all earlier versions and among each other. Nevertheless, it will introduce

3.6. JDO-Query Language

new interesting additional features.

One of the main targets had been to specify a

The aim of the JDO-Query Language is to provide standard object/relational mapping to improve

a simple query grammar that is familiar to Java JDO’s acceptance among the general program-

programmers and that can be executed by the ming public. Standardized mapping and runtime

behavior will improve portability between differ- and common interface is required to meet busi- ent JDO implementations and will increase utility ness requirements.

of vendor independent tools. 2

JDO will meet these requirements in most

cases. It is a standardized interface-based defini-

Furthermore, JDO 2.0 will introduce an at- tion of object persistence, which is supported by

tach/detach API, which will simplify handling leading vendors.

objects in multi-tier applications. For instance, an application has to transfer an object to a client and

Provided transparency will help to reduce allow the client to modify its states. Afterwards,

modeling and programming efforts, compared to the object has to be returned and the modifica-

ordinary JDBC and SQL usage, which neverthe- tions done have to be saved.

less is not obsolete in specific use cases. Further- more, the abstraction of specific data storage will

Maybe, the most important improvements had lead to an improved portability of the whole ap-

been done on the JDO-Query Language. Its capa- plication.

bilities had been enhanced a lot, compared to JDO

1.0. The JDO-QL will now support aggregates,

The programmer itself will benefit in an API named queries, projections and additional func-

for accessing persistent data with object model tions for string-related and mathematic opera-

information only and tools which provide this tions.

transparency by automated code enhancement. While JDO 1.0 may not suit anyone, JDO 2.0

In JDO 1.0 all query results had been a collec- tion of objects identified by the query. Since addi- will bring a lot of promising improvements and tion of projections and aggregates in JDO 2.0 a may be considered when choosing a persistence framework.

result can be an array of objects, which represents a table of records with named columns.

References

The newly supported aggregate functions are count(), sum(), avg(), min(), and max(). The follow- [JDOSPEC] Java Data Objects Specification

ing functions had been introduced to enhance

http://jcp.org/aboutJava/communityprocess/final

string and math capabilities:

/jsr012/index2.html

• get(Object) applies to Map types

[JDO20DRAFT] Java Data Objects 2.0 Public Draft http://jcp.org/aboutJava/communityprocess/pr/j

• containsKey(Object) applies to Map types sr243/index2.html

• containsValue(Object) applies to Map types [FMC] Fundamental Modeling Concepts

• toLowerCase() applies to String type http://www.f-m-c.org/notation-reference/

• toUpperCase() applies to String type [JDOC] JDO Java Doc

• indexOf(String) applies to String type http://java.sun.com/products/jdo/javadocs/

• matches(String) applies to String type, but only

card matches.

Core Java Data Objects, Prentice Hall PTR, 2003

• substring(int, int) applies to String type [JDOAW2003] Robin M. Roos,

• Math.abs(numeric) Java Data Objects, Addison Wesley, 2003

• Math.sqrt(numeric) [JDOO2003] David Jordan and Craig Russell,

• JDOHelper.getObjectId(Object) static method in Java Data Objects, O’Reilly, 2003

JDOHelper, allows using the object identity of

Java Data Objects in der Praxis,

Javamagazin 06/2004

5. Conclusion

Persistence is one of the most important concepts in business applications. Therefore, an easy to use