A Comparative Analysis of Object-Relational Mappings For Java

INSTITUTE OF COMPUTING SCIENCE
POZNAN UNIVERSITY OF TECHNOLOGY
University of Applied Sciences at Braunschweig/Wolfenbuettel

Institute of Industrial Computer Science
“A Comparative Analysis of Object-relational mappings for Java”
Master Thesis
Sudhakar Pothu
Braunschweig, June 2008
1
A Comparative Analysis of Object-relational mappings for Java
Master Thesis
Sudhakar Pothu
30684785
sudhakar.pothu@gmail.com
June, 2008
Supervisors:
Prof. Dr. rer. nat. Klaus Harbusch
Prof. Dr. Maciej Zakrzewicz
Submitted in partial fulfillment of the requirements for the degree

Master of Science in Computer Science.
The thesis defense will take place on 11th of July in Poznan at Poznan University of Technology.
University of Applied Sciences Braunschweig/Wolfenbuettel, Germany

Poznan University of Technology, Poznan, Poland
2008
2
ABSTRACT
While object-oriented programming and high-performance databases are now mainstream,

programmers continue to struggle with persistent storage of objects. Juggling object persistence with
requirements for simplicity, flexibility, maintainability, transparency and scalability can rattle even the
most hardened architect. Especially, in today's Internet-driven multi tier Java applications, the approach
to managing persistent data has been key design decision. This paper examines and does comparative
study on Object-relational mapping technologies for Java. Criteria for comparative analysis has been
defined and study been done on JDBC, ORM frameworks: Hibernate, JPOX JDO and ODBMS db4o
using an example application. This paper will prove useful for persons who are looking to adapt a
persistent strategy for Java application's.
3
Declaration of Honor
I hereby declare in lieu of oath that the work here presented was completed independently by me
without the help of any resource materials other than those stated. The direct and indirect idea taken
from other sources have been labeled as such.
The work has not been previously submitted to any other review board nor has it been released in this
or in any similar form.
Braunschweig, Germany, July 2008.
_____________________________ .
Sudhakar Pothu
4
Preface
This study is performed as part of the master's programme in Computer Science during 2007-2008. It
has been very useful and valuable experience and I have learned a lot during the study, not only about
the topic at hand also to manage the work in the specified time. However, this workload would not have
manageable if I had not received help and support from a number of people who I would like to
mention.
First of all, I would like to thank my Professors, Prof. Dr. Maciej Zakrzewicz for giving me his idea for
a comparative analysis on Object-relational mappings for Java and Professor Klaus Harbusch for his
help and supervision during the writing of thesis.
I would also like to extend my gratitude to the people on online communities, especially Hibernate,
JPOX and db4o. Without online communities my research would have been very difficult to be finished
on time.
I have had a wonderful time doing the research and writing this thesis, and I have learned a lot that will
be very valuable in my next step as a programmer.
5
Table of Contents
Chapter 1. Introduction............................................................................................................................10
1.1.Objective and Research Question:.................................................................................................11
1.2.Method:..........................................................................................................................................12
1.2.1. Literature:..............................................................................................................................12
1.2.2. Model:...................................................................................................................................13
1.2.3. Case study:............................................................................................................................13
1.2.4. Comparative study:...............................................................................................................13
1.3.Outline...........................................................................................................................................14
Chapter 2. About Object-Relational mapping..........................................................................................16
2.1.Introduction to object:...................................................................................................................16
2.1.1. Object-oriented programming (OOP):..................................................................................16
2.1.2. Objects in object oriented programming:.............................................................................17
2.1.3. Basics of Object-oriented programming:..............................................................................17
2.2.Introduction to Java:......................................................................................................................19
2.3.Introduction to Databases:.............................................................................................................19
2.3.1. Database management system (DBMS):..............................................................................19
2.3.2. Relational Database management system (RDBMS):..........................................................20
2.3.3. Object-oriented database management system (OODBMS):...............................................21
2.4.Introduction to persistence:...........................................................................................................21
2.4.1. Persistence in Object-oriented applications:.........................................................................22
2.4.2. Persistence in Java:...............................................................................................................22
2.5.The O/R impedance mismatch:.....................................................................................................23
2.6.Introduction to Object-relational mapping:...................................................................................24
2.7.Object-relational mapping (ORM) tools:......................................................................................24
2.8.Definitions, acronyms and abbreviations:.....................................................................................26
Chapter 3. Comparative analysis criteria.................................................................................................27
3.1.The ORM comparative analysis criteria:.......................................................................................27
3.2.Criteria description:.......................................................................................................................30
3.2.1. General criteria:....................................................................................................................30
3.2.2. ORM specific criteria:..........................................................................................................36
3.3.Chosen ORM candidates:..............................................................................................................42
3.3.1. JDBC:....................................................................................................................................43
3.3.2. Hibernate:..............................................................................................................................44
3.3.3. JPOX (Java persistent objects) JDO:....................................................................................46
3.3.4. Db4o (Database for objects) ODBMS:.................................................................................47
3.4.Chosen example for ORM candidates implementation:................................................................48
Chapter 4. ORM Implementations...........................................................................................................52
4.1.JDBC Implementation:..................................................................................................................52
4.2.Hibernate Implementation:............................................................................................................58
4.3.JPOX JDO Implementation:..........................................................................................................64
4.4.Db4o Implementation:...................................................................................................................72
Chapter 5. Comparative analysis results:.................................................................................................78
5.1.Comparison of general criteria:.....................................................................................................78
6
5.2.Comparison of ORM specific criteria:..........................................................................................80
5.3.Comparison of performance:.........................................................................................................88
5.3.1. Use case specific comparison:..............................................................................................88
5.3.2. CRUD comparison:...............................................................................................................91
5.4.Recommendations and conclusion:...............................................................................................95
Bibliography.............................................................................................................................................99
Appendix A............................................................................................................................................102
7
Illustration Index
Illustration 1: Thesis outline.....................................................................................................................14
Illustration 2: Object-relational mapping architecture.............................................................................24
Illustration 3: JDBC Architecture.............................................................................................................44
Illustration 4: Hibernate Architecture.......................................................................................................45
Illustration 5: JPOX Architecture.............................................................................................................47
Illustration 6: RDBMS - db4o's Object Database ...................................................................................48
Illustration 7: High level architecture of ATM Banking application........................................................49
Illustration 8: High level architecture of Persistence layer......................................................................50
Illustration 9: JDBC implementation - Persistence layer class diagram..................................................54
Illustration 10: Exceptions class diagram.................................................................................................57
Illustration 11: Hibernate implementation - Persistence layer class diagram..........................................63
Illustration 12: JPOX JDO implementation - Persistence layer class diagram........................................71
Illustration 13: Db4o implementation - Persistence layer class diagram.................................................76
Illustration 14: administrator use case – performance comparison chart.................................................89
Illustration 15: User use case - performance comparison chart...............................................................90
Illustration 16: Write - comparison chart.................................................................................................91
Illustration 17: Read comparison chart....................................................................................................92
Illustration 18: Update comparison chart.................................................................................................93
Illustration 19: Delete - performance comparison chart...........................................................................94
Illustration 20: User use case diagram...................................................................................................105
Illustration 21: Administrator use case diagram.....................................................................................106
Illustration 22: ATM banking application Domain class diagram..........................................................107
Illustration 23: ATM banking application EER diagram........................................................................108
8
Index of Tables
Table 1: Definitions, acronyms and abbreviations...................................................................................26
Table 2: Comparison criteria....................................................................................................................30
Table 3: Chosen ORM tools for comparative analysis.............................................................................43
Table 4: Tools used for implementation...................................................................................................51
Table 5: Comparison of general criteria...................................................................................................80
Table 6: Comparison of ORM specific criteria........................................................................................87
Table 7: administrator use case performance comparison........................................................................89
Table 8: User use case - performance comparison...................................................................................90
Table 9: Create objects performance comparison....................................................................................91
Table 10: Read objects performance comparison.....................................................................................92
Table 11: Update objects performance comparison.................................................................................93
Table 12: Delete objects - performance comparison................................................................................94
9
Introduction
Chapter 1. Introduction
Today's Internet-driven view of information systems is helping to popularize Java as an application

development language. Developers are extensively using Java to create multi tier application
architectures that often integrate relational data stores with new data types, in order to package
information in easier-to- use, dynamic ways. Java's object-oriented nature is ideally suited to this new
world. Using objects, Java developers can encapsulate both data and data manipulation methods to give
applications a runtime dynamism and self-contained intelligence that is difficult to achieve using other
methods. Java application developers need to be able to store these Java objects-technically, to give
them persistence-in order to take advantage of these capabilities.
The approach to managing persistent data has been a key design decision in every Java software
project. For several years, persistence has been a hot topic of debate in the Java community. Many
developers don’t even agree on the scope of the problem. Is persistence a problem that is already solved
by relational technology and extensions such as stored procedures, or is it a more pervasive problem
that must be addressed by special Java component models, such as EJB entity beans? Should we hand-
code even the most primitive CRUD (create, read, update, delete) operations in SQL and JDBC, or
should this work be automated? How do we achieve portability if every database management system
has its own SQL dialect? Should we abandon SQL completely and adopt a different database
technology, such as object database systems? Debate continues, but a solution called object-relational
mapping (ORM) now has wide acceptance.
In this Master thesis paper, I examine the development issues surrounding Java object storage,
including a brief overview of the JDBC, Java API for executing SQL statements, Object-relational
10
Introduction
mapping, a solution that adds object persistence to Java and also Object oriented databases. I compare
object persistence in a example Java application with couple of Object-relational mapping tools, with
Object-oriented database and also the much greater level of effort required to implement the same
application using the lower level JDBC interface, which supports Java object storage in relational
databases. This thesis is helpful for those interested in using Object-relational mapping tools, such it
gives an idea of what to look for in an Object-relational mapping tool.
1.1. Objective and Research Question:

There are many Object-relational mapping tools that exist in market today that map relational databases
into Java-object models. This Master thesis paper provides an understanding of what Object-relational
mapping is? with comparison analysis and technical review of couple of popular ORM projects in the
market as of today namely, Hibernate and JPOX JDO. It is hoped that this will prove useful to anyone
who is working on Java platform, databases and trying to select a tool that does Object-relational
mapping.
The key contribution of this paper is to discuss the core technical problems that need to be
solved in Object-relational mapping scenario, and then classify the Object-relational mapping tools
according to how they attempt to solve these problems. It is therefore focused on the general design of
each tool, specific performance and reliability issues. Most of the analysis is based on direct experience
using each tool, testing performance and based on reading product documentation.
The research question addressed in this thesis is the following:
“Is ORM framework a replacement for JDBC, how to select an Object-relational mapping tool
which is suitable for the Java project in Hand, and can relational databases be replaced with
Object-oriented databases”
To answer this question, the following subquestions are used:
11
Introduction
● What is mismatch problem

● What are the challenges in using JDBC as persistence solution
● Are there characteristics that make Object-relational mapping tool unique that are relevant to a
particular Java-project, and if so, what are they?
● Which criteria can be defined for Object-relational mapping tool selection and evaluation?
● What are the advantages in using ODBMS
In order to answer these questions the subject of Object-relational mapping should be studied throughly
and also Object-relational mapping tool market will be studied using literature and information from
the Internet. With this knowledge a model for Object-relational mapping tool evaluation is created
that will give insights into the unique characteristics of Object-relational mapping tool relevant to
those who intend to use it. This model should give an answer to the question which ORM tool should
be used in a software project. To give experimental results not only the theoretical study is enough but
an example must be implemented with JDBC, on chosen ORM tools and with an ODBMS.
1.2. Method:
The method used to construct this thesis consists of four parts: literature study, construction of the
Model (comparative analysis criteria), case study (implementation of ORM candidates on example) and
the Comparative study itself.
1.2.1. Literature:
Comparison analysis of Object-relational mapping tools is a relatively new field of study in the
academic world. The number of articles written on the subject is not high. To start the literature study,
general Object-relational mapping articles and information is used to get a good global idea of Object-
relational mapping. This literature will also be the basis for the first chapter. In order to establish the
criteria for the comparative analysis, literature on comparing Object-relational mapping tools such as
Hibernate and JPOX JDO are consulted. Because scientific literature from the academic libraries may
12
Introduction
not offer enough to complete the research, other sources need to be explored as well, by using search
engines on the Internet, for example. Of course the validity of non-scientific resources is verified.
1.2.2. Model:
From the literature mentioned above, the Comparison analysis criteria are identified. These will be the
key terms of the evaluation model for Comparison analysis of Object-relational mapping tools. The
model consists of two parts. The first part describes the background of the criteria, what effect they
have on the Object-relational mapping tool and why they are important. In the second part the
evaluation process is described, explaining the method for identifying the key values for each criterion.
1.2.3. Case study:
The case study will be performed on ATM Banking application. This application category was chosen
because it concerns reasonably large applications, targeted at institution wide use at banking
institutions, which warrants a full evaluation. A list of requirements is constructed using websites on
Banking applications. This application's persistence layer will be developed using each ORM
candidate. A step by step process implementation will be described and the model created in the
previous step will be followed to identify the symptoms of these candidate tools.
1.2.4. Comparative study:
The comparative study is based above three steps. The criteria formed will be analyzed for each ORM
candidate, this analysis is based on literature, experience and experimentation during case study. Both
general criteria and ORM specific criteria will be elaborated for each ORM candidate in tabular form
for easy examining. A special comparison will be done on performance using the test execution times
of each unit test performed during case study.
13
Introduction
1.3. Outline
Figure 1 gives a graphical representation of the structure of this thesis.
Illustration 1: Thesis outline
Chapter 2 is an introduction to Object-relational mapping, including the Object-relational mapping

tools. In chapter 3 the criteria for evaluation is discussed, starting by a description of the criteria in
section 3.2, followed by a description of general criteria in section 3.2.1 and the ORM specific criteria
14
Introduction
in 3.2.2. A description of chosen ORM candidates is given in 3.3 followed by the description of
example taken in 3.4. In chapter 4 the ORM implementation on example are explained step by step.
Section 4.1 is dedicated for JDBC implementation, followed by Hibernate implementation in 4.2, JPOX
JDO implementation in 4.3 and Db4o implementation in 4.4. Finally, the Comparative study is done in
chapter 5, for general criteria is done in 5.1, followed by ORM specific criteria in 5.2 and comparison
of performance in 5.3. In section 5.4, recommendation and conclusion answers the research question in
1.1, and also gives recommendations for further research.
15
Introduction
Chapter 2. About Object-Relational mapping
As the topic stated on cover page “A Comparative analysis of Object-relational mappings for Java”
this paper deals on the subject matter called Object-relational mapping and some tools that are present
in market at this present moment to deal with this subject. As you read along this chapter you will
understand each and every word that is used in the stated topic and the research topic that is formed by
combination of these words.
2.1. Introduction to object:

In computer science an Object is a discrete item that can be selected and maneuvered. In its simplest
embodiment, an object is an allocated region of storage.
2.1.1. Object-oriented programming (OOP):
Object-oriented programming (OOP) is a programming language model organized around "objects"

rather than "actions" and data rather than logic. Historically, a program has been viewed as a logical
procedure that takes input data, processes it, and produces output data. The programming challenge was
seen as how to write the logic, not how to define the data. Object-oriented programming takes the view
that what we really care about are the objects we want to manipulate rather than the logic required to
manipulate them.
16
About Object-Relational mapping
The first step in OOP is to identify all the objects you want to manipulate and how they relate to
each other, an exercise often known as data modeling. Once you've identified an object, you generalize
it as a class of objects and define the kind of data it contains and any logic sequences that can
manipulate it. Each distinct logic sequence is known as a method.
2.1.2. Objects in object oriented programming:
As stated above in object-oriented programming, an object is an instance (or instantiation) of a class.

The class object contains a combination of data and the instructions that operate on that data, making
the object capable of receiving messages, processing data, and sending messages to other
objects. Therefore an object facilitates for
● data members that represent the data associated with the object.
● methods that access the data members in predefined ways.
Examples of objects range from human beings (described by name, address, and so forth) to
buildings and floors (whose properties can be described and managed) down to the little widgets on
your computer desktop (such as buttons and scroll bars).
2.1.3. Basics of Object-oriented programming:
Object-oriented modeling techniques are concerned with (primarily) behavior. It is beyond the scope of
this paper to explain all about Object-Oriented programming, but I tried to explain some basic terms
which are used in Object-oriented modeling in this section. They are the following:
Class:
A class is a user-defined data type that defines a collection of objects that share the
same characteristics.
Object:
17
A particular object, an instance of a class.

Instance:
A member of a class, one can have an instance of a class or a particular object.
Method:
A method is the processing that an object performs. When a message is sent to an
object, the method is implemented. In other terms it is an object's abilities.
Message passing:
Message passing is the process by which an object sends data to another object or asks
the other object to invoke a method.
Inheritance:
Inheritance is the ability of one class of objects to inherit properties from a higher class.
‘Subclasses’ are more specialized versions of a class, which inherit attributes and behaviors
from their parent classes, and can introduce their own
Encapsulation:
Encapsulation refers to the bundling of data with the methods that operate on that data,
it conceals the functional details of a class from objects that send messages to it.
Abstraction:
Abstraction is the process of generalization by reducing the information content of a
class, which means simplifying complex reality by modeling classes appropriate to the
problem, and working at the most appropriate level of inheritance for a given aspect of the
problem.
Polymorphism:
Polymorphism refers to the ability to process objects differently depending on their data
type or class. More specifically, it is the ability to redefine methods for derived classes.
Polymorphism allows you to treat derived class members just like their parent class members.
More precisely, Polymorphism in object-oriented programming is the ability of objects
belonging to different data types to respond to method calls of methods of the same name, each
one according to an appropriate type-specific behavior.
18
2.2. Introduction to Java:

Java is a high-level Object-oriented programming language, influenced in various ways by C, C++, and
Smalltalk, with ideas borrowed from other languages as well. Its syntax was designed to be familiar to
those familiar with C-descended "curly brace" languages, but with arguably stronger OO principles
than those found in C++, static typing of objects, and a fairly rigid system of exceptions that require
every method in the call stack to either handle exceptions or declare their ability to throw them.
Garbage collection is assumed, sparing the developer from having to free memory used by obsolete
objects.
A typical Java program creates many objects, which as you know (by above), interact by
invoking methods through these object interactions, a program can carry out various tasks, such as
implementing a GUI, running an animation, sending and receiving information over a network or
storing the information. Once an object has completed the work for which it was created, its resources
are recycled for use by other objects.
2.3. Introduction to Databases:

A database is a collection of information that is organized so that it can easily be accessed, managed,
and updated. In one view, databases can be classified according to types of content: bibliographic, full-
text, numeric, and images. In computing, databases are sometimes classified according to their
organizational approach.
2.3.1. Database management system (DBMS):
Database management system (DBMS) is a collection of programs that enables you to store, modify,
and extract information from a database. There are many different types of DBMS's, ranging from
small systems that run on personal computers to huge systems that run on mainframes. A DBMS
19
includes:
● A modeling language to define the schema of each database hosted in the DBMS, according to
the DBMS data model.
● Data structures (fields, records, files and objects) optimized to deal with very large amounts of
data stored on a permanent data storage device (which implies relatively slow access compared
to volatile main memory).
● A database query language and report writer to allow users to interactively interrogate the
database, analyze its data and update it according to the users privileges on data.
● A transaction mechanism, that ideally would guarantee the ACID properties, in order to ensure
data integrity, despite concurrent user accesses (concurrency control), and faults (fault
tolerance).
2.3.2. Relational Database management system (RDBMS):
Relational database management system is a type of DBMS that stores data in the form of related
tables. Relational databases are powerful because they require few assumptions about how data is
related or how it will be extracted from the database. As a result, the same database can be viewed in
many different ways.
An important feature of relational systems is that a single database can be spread across several
tables. This differs from flat-file databases, in which each database is self-contained in a single table.
RDBMS consists of guidelines such as the avoidance of duplicating data using a technique called
normalization and how to identify the unique identifier for a database record. Almost all full-scale
business database management system's (DBMS), including Oracle, DB2, SQL Server, MySQL, etc., is
a relational DBMS (RDBMS).
A RDBMS is basically based on the relational model as introduced by E. F. Codd in 1969. The
relational model for database management is a database model based on predicate logic and set theory
20
with aims that included avoiding, without loss of completeness, the need to write computer programs to
express database queries and enforce database integrity constraints. The word "Relation" is a
mathematical term for "table", and thus "relational" roughly means "based on tables". It did not
originally refer to the links or "keys" between tables, contrary to popular interpretation of the name.
Most popular commercial and open source databases currently in use are based on the relational model.
However, many of the early implementations of the relational model did not conform to all of Codd's
rules, so the term gradually came to describe a broader class of database systems. At a minimum, these
systems:
• presented the data to the user as relations (a presentation in tabular form, i.e., as a collection of
tables with each table consisting of a set of rows and columns.
• provided relational operators to manipulate the data in tabular form.
2.3.3. Object-oriented database management system (OODBMS):
An object-oriented database management system (OODBMS), sometimes shortened to ODBMS for

object database management system), is a database management system (DBMS) that supports the
modeling and creation of data as objects. This includes some kind of support for classes of objects and
the inheritance of class properties and methods by subclasses and their objects. There is currently no
widely agreed-upon standard for what constitutes an OODBMS, and OODBMS products are
considered to be still in their infancy. But the fact is that OODBMS technology is the perfect match for
using in OO development environment is obvious from the very name. Though RDBMS has a wide
support in tools and methods of using in OO environment there will always be an overhead of the
translation from the object to relational world, commonly known as object-relational impedance
mismatch.
2.4. Introduction to persistence:

In computer science, persistence refers to the characteristic of data that outlives the execution of the
21
program that created it. Almost all applications require persistent data. Persistence is one of the
fundamental concepts in application development. If an information system didn’t preserve data when
it was powered off, the system would be of little practical use.
2.4.1. Persistence in Object-oriented applications:
In an object-oriented application, persistence allows an object to outlive the process that created it. The
state of the object may be stored to disk and an object with the same state re-created at some point in
the future. This application isn’t limited to single objects—entire graphs of interconnected objects may
be made persistent and later re-created in a new process.
2.4.2. Persistence in Java:
Most Java applications involve creating, storing, and searching data in some form; in other words: use a
database (mostly RDBMS). This is referred to as persisting data often called CRUD, for Create, Read,
Update, and Delete. Databases are integral parts of almost all Java computing systems. The approach to
managing persistent data is a key design decision in every Java project. Given that persistent data isn’t
a new or unusual requirement for Java applications, you’d expect to be able to make a simple choice
among similar, well-established persistence solutions.
For several years, persistence has been a hot topic of debate in the Java community. Many
developers don’t even agree on the scope of the problem. Is persistence a problem that is already solved
by relational technology and extensions such as stored procedures, or is it a more pervasive problem
that must be addressed by special Java component models, such as EJB entity beans? Should we hand-
code even the most primitive CRUD (create, read, update, delete) operations in SQL and
JDBC, or should this work be automated? How do we achieve portability if every database
management system has its own SQL dialect? Should we abandon SQL completely and adopt a
different database technology, such as object database systems? Debate continues, but a solution called
object/relational mapping (ORM) now has wide acceptance.
22
2.5. The O/R impedance mismatch:

The object-oriented paradigm is based on proven software engineering principles. The relational
paradigm, however, is based on proven mathematical principles. Because the underlying paradigms are
different the two technologies do not work together seamlessly. The impedance mismatch becomes
apparent when you look at the preferred approach to access: With the object paradigm you traverse
objects via their relationships whereas with the relational paradigm you join the data rows of tables.
This fundamental difference results in a non-ideal combination of object and relational technologies. To
succeed using objects and relational databases together you need to understand both paradigms, and
their differences, and then make intelligent tradeoffs based on that knowledge. [ADTSA06]
The following are the common mismatches between both paradigms:
● The problem of granularity
● The problem of subtypes (inheritance, polymorphism)
● The problem of identity
● Problems relating to associations
● The problem of data navigation
23
2.6. Introduction to Object-relational mapping:
Object-relational mapping is a programming

technique for converting data between
incompatible type systems in relational databases
and object-oriented programming languages. It
mediates the application’s interaction with a
relational database, leaving the developer free to
concentrate on the business problem at hand. As
shown in Illustration 2, an object relational
mapper sits between the object model used by an
application and the relational model used by a
conventional RDBMS system. It's a useful piece
of software, as it allows one to blend the best of
both worlds. The application can be written in
Illustration 2: Object-relational mapping
terms of objects, and the database can be managed architecture
using conventional tools.
2.7. Object-relational mapping (ORM) tools:

An Object-relational mapping (ORM) tool is an implemented ORM framework that performs a way of
automatically mapping normal Java objects to an SQL database. In other words, it loads, searches, and
saves your data model objects. Rather than writing cumbersome SQL insert, update, and select
commands, the framework will take care of the boilerplate code through some kind of automation.
Object-relational mapping tools establish a bidirectional link with data in a relational database and
24
objects in code, based on a configuration and by executing SQL queries (dynamic most of the time) on
the database.
An ORM tool solves the difficult problem of storing objects in a relational database. You tell the
framework how your domain model maps to the database schema, and it takes care of getting your
objects in and out of the database. This enables you to focus on solving your business problems rather
than writing lots of low-level database access code. The key features of an ORM framework are as
follows:
● Declarative mapping between the object model and database schema—Describes how the
object model’s classes, attributes and relationships are mapped to database table and columns
and used by the ORM framework to generate SQL statements
● An API for creating, reading, updating, and deleting objects—Called by the domain model’s
repositories to manipulate persistent data
● A query language—Used to efficiently find persistent objects that satisfy search criteria
● Support for transactions—Maintains data integrity and handles concurrent updates
● Lazy and eager loading—Optimizes performance by controlling when objects are loaded
● Caching—Improves performance by minimizing database accesses
● Detached objects—Enables persistent objects to be passed between the presentation tier and the
business tier
There are both free and commercial tools available in market today that perform object-
relational mapping. Below you see some of the well known ones,
• Cayenne, apache, open source for java
• Ebean, open source ORM Framework
• Enterprise Objects Framework, Mac OS X/Java, part of Apple WebObjects
• Hibernate, open source ORM Framework, widely used
• iBATIS, maintained by ASF, and with .NET port.
25
• Java Data Objects (JDO)
• JPOX, open source JDO 2 reference implementation
• Kodo, commercial implementation of both the JDO and JPA API.
• OpenJPA, apache, open source, supports JPA API.
• TopLink by Oracle
• WebObjects commercial from Apple, includes EOF as the object-relational mapping layer
In particular, Hibernate has become the de facto ORM. Hibernate is an ambitious project that
aims to be a complete solution to the problem of managing persistent data in Java. It mediates the
application’s interaction with a relational database, leaving the developer free to concentrate on the
business problem at hand.
2.8. Definitions, acronyms and abbreviations:
ORM Object Relational Mapping

SQL Structured Query Language
DDL Data Definition Language
DML Data Manipulation Language
RDBMS Relational Database-Management-System
ODBMS Object-oriented database management system
DB Database
API Application Programming Interface
GUI Graphical User Interface
POJO Plain Old Java Object
CRUD Create/retrieve/update/delete
XML Extensible Mark-up Language
XSD XML Schema Definition
Metadata Data that describes data ( or in other terms structured data which
describes the characteristics of a resource)
EER Enhanced Entity-Relationship
IDE Integrated Development Environment
GPL General public license
GNU, LGPL Lesser General Public License
Table 1: Definitions, acronyms and abbreviations
26
Chapter 3. Comparative analysis criteria
In this chapter, a model criteria is proposed for comparative analysis of Object-relational mappings
using an approach adopted to the general and unique characteristics of Object-relational mapping tools.
The criteria that are used were derived from Object-relational mapping literature, among which
are three articles giving advice on criteria for selecting Object-relational mapping tool. These sources
are discussed in the next section. In order to understand their importance and value, the section 3.2
gives a description of each criterion. The comparative analysis is done on chosen candidates, in section
3.3 the chosen ORM candidates are described with the reason of why they were chosen. The evaluation
process, consisting of an example Java application is described in section 3.4 with the tools used for
implementation.
3.1. The ORM comparative analysis criteria:

The criteria for the Comparative analysis of ORM were established using Object-relational mapping
literature on the subject of Object Relational Tool Comparison. Because scientific literature is still
somewhat scarce on the subject, web searches were needed to find the required resources. The web
searches were done to find the most prominent articles on Object Relational Tool Comparison, Object
Relational Tool success factors and Object Relational Tool evaluation. Three articles giving advice on
criteria for selecting Object-relational mapping tool were found. In order to identify the criteria that
give a good general idea of the Object-relational mappings that needs to be evaluated, all criteria were
listed and the terms covering the same areas were grouped together. The criteria that were mentioned in
27
Comparative analysis criteria
some way in at least three sources were included in this model. The three sources are
listed below.
I. “Choosing an object-relational mapping tool” by Fabrice Marguerie
http://madgeek.com/Articles/ORMapping/EN/mapping.htm (Retrieved on May 05, 2008)
II. Object Relational Tool Comparison

http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison (Retrieved on May 05, 2008)
III. “How-To-Select an Object-Relational Mapping Tool for .NET” by By Jason Mauss

http://www.howtoselectguides.com/dotnet/ormapping/#dal (Retrieved on May 05, 2008)
The criteria is divided into two sections General and ORM specific. General section is criteria
applicable to any software and ORM specific criteria is applicable to ORM tools. The following table
list the general criteria and ORM specific criteria in two adjacent columns. Later in section 3.2 each
criteria is explained in detail.
28
General Criteria ORM specific Criteria
Basic features
● Performance
• Inheritance
● Resource consumption
• Relations
● Complexity (or simplicity...)
• Transactions
● Ease of use, time to be up and running
• Aggregations
● Flexibility
• Grouping
● Documentation
Extended features
● Maturity or Longevity
• Supported databases
● Frequency of the updates, bug fixes,
• query language
evolutions
Flexibility
● Support (forums, community)
• Customization of queries
● Vendor's reputation and stability
• Support for SQL joins
● Source code provided (or not)
• Concurrency management
● Support for multiple platforms
• Data type support for RDBMS
● Price
• Single class to multiple tables
• single table to multiple objects
Assistance, ease of use
• GUI to set up the mapping
• Generation of the classes
• Generation of the database schema
Optimizations, performance, design:
• Global performance
• Lazy loading
• Caching
• Optimized queries
• Handle circular references
• Handle cascade updates
• Bulk updates or deletions
Evolution, compatibility
• Maintainability
• Possibility to move to a new mapping tool
• Serialization
• Distributed objects
Additional features
• Freedom in the design of the classes
• Less constraints as possible on the database
schema
• State information on data
• External mapping file
• Support for disconnected mode
• Interceptors and delegation mechanisms
• Support for stored procedures
29
• constraints handling
• Filtering objects in memory
• Deferred operations cache
Table 2: Comparison criteria
3.2. Criteria description:

The criteria are each described in the following subsections, giving background information and
explaining why the criterion is important for comparative analysis.
3.2.1. General criteria:
The general criteria are each described in the following subsections, giving background information
and explaining why the criterion is important. The following criteria are not ORM specific it is
common to the selection of any piece of software.
● Performance: One of the most difficult things in enterprise application development is

guaranteeing performance and scalability of an application. Performance is usually considered
to be the reaction time of a request/response based application. If you click a button, you expect
a response in half a second. Or, depending on the use case, you expect that a particular event (or
batch operation) can be executed in a reasonable time frame. Naturally, reasonable depends on
the case and usage patterns of some application functionality. (JPHBK08)
A performance bottleneck can be anything you consider a programming mistake or bad design
—for example, the wrong fetching strategy, a wrong query, or bad handling of the session
and persistence context. Testing a system for reasonable performance is usually part of the
acceptance tests. In practice, performance testing is often done by a dedicated group of end
user testers in a lab environment, or with a closed user group in real-world conditions. Pure
automated performance tests are rare.
You can also find performance bottlenecks with an automated scalability test; this is the
30
ultimate goal. Stress and load tests must consider the following rules:
Test performance with real-world data sets: Test data should be as close as possible to the data
the system will work on in production, with the same amount, distribution, and selectivity. Test
must not be performed with a data set that can fit completely into the cache of a hard disk on the
database server.
Test performance with real use cases: If your application has to process complex transactions
(for example, calculating stock market values based on sophisticated statistical models), you
should test the performance of the system by executing these use cases. Analyze your use cases,
and pick the scenarios that are prevalent—many applications have only a handful of use cases
that are most critical. Avoid writing micro benchmarks that randomly store and load a few
thousand objects; the numbers from these kinds of tests are meaningless.
● Resource consumption (memory): How a piece of software impacts on your IT infrastructure

depends on a lot of factors – some are foreseeable, some are not. You may know what the load
on your network is now, and how many people will be using the software to start off with, but it
can be very difficult to predict how things will happen in the future. How will your network
expand? Will you employ more people? What other software will the company use? What
processes will be running on different machines? How will your users’ habits change?
Applications using an object/relational persistence layer are expected to outperform applications

built using direct JDBC because of the potential for caching. Caching in turn cause memory
consumption, therefore this is an important criteria for comparative analysis for Object-
relational mapping.
For applications accessing data that does not change frequently or only needs read-only access,
caching can play an important role. Different methods of caching can be employed among O/R
Mappers like a disk-based cache or in-memory. Additionally, some O/R Mappers can cache the
31
object-relational mapping information in order to remove the need for accessing the mapping
file repeatedly. As one of the most important requirements for implementing an O/R Mapping
component is that there be no loss of performance, caching can make a big difference in
whether your performance requirements are met or not.
● Complexity (or simplicity...): complexity is a measure of the resources expended by a system

while interacting with a piece of software to perform a given task. If the interacting system is a
computer, then complexity is defined by the execution time and storage required to perform the
computation. If the interacting system is a programmer, then complexity is defined by the
difficulty of performing tasks such as coding, debugging, testing, or modifying the software.
The term software complexity is often applied to the interaction between a program and a
programmer working on some programming task. [KSTGASCM86]
● Ease of use, time to be up and running: Most organizations rank ease of use as a high priority
on their list of criteria. One of the most compelling reasons one software package is selected
over competing products is the ease-of-use issue. This is true because many people with varying
skill levels throughout the organization must use the planning tool. Employing an easy-to-use
software tool does not require that the user possess a great deal of specialized knowledge nor
training to produce the end product. That is to say, ease of use is a characteristic attributable to
the process of using a software tool. The tool is graded on the simplicity of its use. Therefore,
ease of use is a process issue. Ease of use is not an end product issue. The end product produced
by the software tool cannot be attributed the characteristic, ease of use. A product issue focuses
on the end result, the plan, not how the plan was processed. [GEOUS08]
● Flexibility: Flexibility has been recognized as a desirable quality of software since the earliest
days of software engineering. Object-oriented programming (OOP) is hailed, among other
reasons, for promoting flexibility. Experienced programmers, however, observe that object-
oriented mechanisms such as inheritance and dynamic binding make programs more flexible
32
only towards the particular shifts they specifically were tailored to accommodate. For example,
it has been established that gratuitous use of inheritance may lead to the problem of ‘fragile
base class’ and yield highly inflexible programs. [EMMSF05]
● Documentation: Using a mapping tool is not always a snap. Check the quality of the
documentation and the provided samples.
There are two main types of documentation [KBOSE05]
I. User documentation
II. Developer documentation
User documentation contains all documents that describe how to use the system. For certain
applications there can be different levels in the user documentation, corresponding with
different user levels and rights. For example, many applications that have an administrator role,
have a separate piece of documentation for administrators. Additionally, there can be various
user-contributed tutorials and How-To, be it on the project’s website or elsewhere.
The other main type of documentation, which plays a much larger role in Open Source
software than in proprietary applications, is developer documentation. A voluntary
decentralized distribution of labor could not work without it. The developer documentation
concerns separate documents on how to add or change the code, as well as documentation
within the source code, by way of comments. The comments usually explain what a section of
code does, how to use and change it and why it works like it does. Though this type of
documentation may exist for proprietary software, it is usually not public to have access to it.
Documentation is often lagging behind the status of the application, since especially
user documentation is often written only after functionality is created.
33
● Maturity or Longevity: Many tools are relatively new, and are still not mature. Some are still
at the beta level, or even alpha.
The longevity of a product is a measure of how long it has been around. It says something
about a project’s stability and chance of survival. A project that is just starting it usually still full
of bugs. The older a project, the less likely the developers will suddenly stop. But age is not
always a guarantee of the chance of survival. First of all, very old software may be stuck on old
technologies and methods, from which the only escape is to completely start over. Some
software has already successfully gone through such a cycle, which is a good sign in terms of
maturity. One thing that needs to be taken into account when products are not very young is
whether or not there is still an active community around it.
● Frequency of the updates, bug fixes, evolutions: The age and activity level of project are
often related. Young projects often have a higher activity level than older ones, because once a
project has stabilized and is satisfactory to most users, the discussions are less frequent and
releases are smaller, containing mostly bug and security fixes. This doesn’t mean that the
activity should ever be slim to none. As mentioned before, no project is ever static. There’s
always something that still needs to be done.
● Support (forums, community): ‘One of the most important aspects of open source tools is the
community’ [KBOSE05]
The user community of an open source ORM project consists of the people that use the
software and participate in some way. One way of participating is by filing bug reports, which
is a report on a problem in the software. This could be something very small, like a typing error
in the text, or something large, like a feature that does not work properly. Another way is giving
feedback on functionality the user would like to be added. Some users turn into developers over
time, and participate in things such as fixing bugs or adding functionality themselves. They
cross the line to the developer community, which is often a line made very thin by encouraging
participation and making the developer community accessible to anyone who is interested. In
34
some cases the user and developer community interact fully in the same discussion areas. The
community of an Open Source project is very important because it is the community that does
most of the testing and provides quality feedback. Instead of using financial resources to put the
software through extensive testing and Quality Assurance(QA), like a proprietary vendor will
do, the Open Source ORM projects have the community as a resource. The more people are
interested in a project, the more likely it is that it will be active and keep going. A large and
active community says something about the acceptance of the tool. If the software was not good
enough to use,there would not be so many people who cared about its development.
There are two types of support for a software product. [KBOSE05]

I. Usage support – the answering of questions on the use of the software
II. Failure support or maintenance – the solving of problems in the software
Often the two get mixed at some level because users do not always know the right way to use
the product. Their support request will start as a problem report and later becomes part of usage
support. The way support is handled is a measure of how seriously the developers work on the
software. One way to check this is to see if there is a separate bug tracker for the software, and
how actively it is being used by both the developers and the users. When the developers use it
but hardly any users seem to participate, the users may not be pointed in the right direction to
report problems. Aside from community support, larger or more popular projects may have paid
support options. The software is free to use, but the user has the option to get professional
support for a fee, either on a service agreement basis where a subscription fee is payed for a
certain period of time, or a per incident fee for each time the user calls on support. The project
leaders themselves may offer something like this, which is the case for the very popular Open
Source database server MySQL (MySQL, 2005). There are companies that offer specialised
support for certain Open Source software. This is called third party support. For example, at the
Mozilla Support web page, it can be seen that DecisionOne offers paid support for Mozilla’s
popular web browser FireFox, the e-mail client Thunderbird and the Mozilla Suite (Mozilla,
2005). The fact that paid support exists for a Open Source product, especially third party
support, is a sign of maturity and a sign the product is taken seriously.
35
● Vendor's reputation and stability: This is a big problem today. There are a lot of tools, but
natural selection is constantly at work. Which products will still be there tomorrow? Some have
already fallen. Time will probably continue to eliminate some actors in this very competitive
market.
● Source code provided (or not): (important in case the vendor disappears)
● Support for multiple platforms: (Java and .NET? Windows and Linux?RDBMS and
ODBMS?)
● Price: This may not be an important criteria for open source ORM tools, as they are free. But if
you can spend some money there are many tools which can ease and speed up development
steps which is unimaginable by open source free tools.
3.2.2. ORM specific criteria:
The criteria specific to ORM are each described in the following subsections, giving background
information and explaining why the criterion is important for ORM. This criteria is mentioned
especially to compare ORM tools like Hibernate and JPOX JDO.
Basic features:
● Transparent Persistence : The automatic mapping of Java objects with database tables and
vice versa is called Transparent Persistence.
● Inheritance: Inheritance is one of the core concepts in OO programming, but supporting

inheritance in your relational database requires you to make some tough decisions.
Implementing an ORM requires support for some or all of those decisions. ORM should handle
inheritance, create hierarchies between entities, and use polymorphism (we are using objects!).
The tools can support a variety of combinations for tables and classes to allow these
36
mechanisms.
● Relations: There are two types of relations in database design: one-to-many and many-to-many.
In a one-to-many relation, multiple rows in one table usually have a reference to a single row in
another table (or quite possibly the same table, depending on the design). When using an ORM
tool relations between multiple entities are typically resolved directly by means of associations,
which are defined within your metadata that will map the entities classes to the underlying
persistence unit. Inside your classes, those associations are usually represented as fields (or
properties) which reference either a single related entity or a whole collection of related entities.
A good ORM should Handle any type of relations (1-1, 1-n, n-n).
● Transactions: Transactions allow you to set the boundaries of a unit of work: an atomic group
of operations. They also help you isolate one unit of work from another unit of work in a
multiuser application. While I might qualify transactions as comparatively unimportant, anyone
who’s written a multi-user web application knows how significant they can be in maintaining
data integrity. An ORM which didn’t support transactions would be sorely crippled indeed.
● Aggregates: By their very nature, our databases contain a lot of data, oftentimes, we're
interested in summarizing our data to determine trends or produce top-level reports. SQL
provides aggregate functions such as SUM, AVG, MIN, MAX, COUNT to assist with the
summarization of large volumes of data. A typical ORM query language should support
aggregate functions which are most commonly used for reporting and other things.
● Grouping (SQL's GROUP BY): GROUP BY was added to SQL because aggregate functions
(like SUM) return the aggregate of all column values every time they are called, and without the
GROUP BY function it was impossible to find the sum for each individual group of column
values. Hence it is an essential criteria for ORM.
Extended features:
● Supported databases: A big advantage of mapping tools is that they provide an abstraction of
37
the underlying database engine. Most of them allow switching easily between RDBMS's
(Relational Database Management Systems). Your application does not even know what the
database is; its only connection to it is via the ORM framework and the JDBC driver. This
means that your development environment can be a cheaper version of the production
environment (as in, using an open source database for development would save you all that
Oracle development licenses cash), and that you can confidently upgrade database versions
without expecting to have to modify the application at all.
● Query language (OQL - Object Query Language): We very frequently have to execute dynamic
queries. It's the case at least with searches based on filters. It is important to be able to use a
powerful query language. ORM should be equipped with a powerful query language that
understands notions like inheritance, polymorphism and association.
Flexibility:
● Customization of queries: We often need to go beyond what is possible with the provided
query language. In these cases, we need to be able to provide custom SQL queries. HQL, which
is a strong point of Hibernate, allows for this. We could also wish a dynamic mapping to be
possible from developer provided SQL queries.
● Support for SQL joins: Support any type of SQL joins (inner join, outer join)
● Concurrency management (support for optimistic and pessimistic approaches)
● Data type support for RDBMS: Support for the data types specific to the database
management system (identity columns, sequences, GUIDs, auto increments).
● Single class to multiple tables: Be able to map a single object to data coming from multiple
tables (joins, views). Most of the tools handle a direct mapping of a class to one table. We often
need more.
38
● Be able to dispatch the data from a single table to multiple objects.
Assistance, ease of use:

● GUI to set up the mapping. Such a graphical tool presents the relational data model and lets
you specify the objects to be created or at least the links between the objects and the tables.
● Generation of the classes: This can speed up the development, even if in a lot of cases we
prefer to map the database to hand-coded classes or to classes generated from UML for
example. Check which scenarios are supported by the tools.
● Generation of the database schema. Some tools work only with a database they generated.
This can be a big constraint, especially if you have to work with a legacy database of course!
Otherwise, it all depends on whether you are an expert in database modeling, or if you prefer
not to have to deal with the database schema. If you have a DBA who takes care of your
databases, or if you prefer to design them by yourself, be sure to select a mapping tool that
doesn't require its own data model.

● Global performance (good implementation of the object-relational mapping concept)
● Lazy loading (the loading of some data is deferred until it's needed)
• for the data through relations
• for some columns. When we want to display just a list of names, we don't need all the
columns of a table to be loaded. We may need the blob fields only at certain point, under
certain conditions, and so it's better to load them only at that time.
● Caching: A major justification for our claim that applications using an ORM persistence layer
are expected to outperform applications built using direct JDBC is because of the potential for
caching. Although we’ll argue passionately that most applications should be designed so that it’s
39
possible to achieve acceptable performance without the use of a cache, there is no doubt that for
some kinds of applications, especially read-mostly applications or applications that keep
significant metadata in the database, caching can have an enormous impact on performance.
Furthermore, scaling a highly concurrent application to thousands of online transactions usually
requires some caching to reduce the load on the database server(s).
• Cache dynamically generated queries, so that they don't get rebuilt at each call.
• Cache some data to avoid too many calls to the data source.
● Optimized queries: update only the modified columns; detect situations where the number of
executed queries can be reduced.
● Handle circular references: Handle circular references without duplication of objects

("account == account.Client.Account")
● Handle cascade updates: Deleting a master record should delete the linked details if wished
so.
● Bulk updates or deletions: When we want to update or delete thousands of records at a time,
it's not possible to load all the objects in memory, while this can be easily and quickly done with
a SQL query (DELETE FROM Customer WHERE Balance < 0). Support from the tool is
welcome to handle such massive operations without having to deal with SQL. Hibernate is not
very good on this point for example.
Evolution, compatibility:
● Maintainability: what happens if the database schema changes? If I need to add a new
collection?
● Possibility to move to a new mapping tool: what would it imply? At what cost?
40
● Serialization: Serialization can be used to persist data outside of the database. Serialization can
be done into a binary format, or more important, in XML. Object-relational mapping tools often
base the development of your applications on the fact that the entities you handle are linked to a
data source with which they communicate directly to reflect updates you perform on them.
Especially when considering service-oriented architectures, the handling of persistence is
delegated to a dedicated layer; the code for persistence is not in the entities themselves.
● Distributed objects: ORM Remoting capabilities; web services; requires support for
serialization
Additional features:
● Freedom in the design of the classes: No base class for the entities; no mandatory interface; no
specific class for collections. Think POJO (Plain Old Java Object).
● Less constraints as possible on the database schema: eg. support for composite data keys
● State information on data: It can be useful to know by looking at an object if the entity has
been added, modified, deleted.
● External mapping file: External mapping file or not? Attributes (annotations) in code or not?
• Advantages of external files: mapping entirely externalized; no intrusion in the classes;
can be generated
• Disadvantages of external files: one or multiple additional files to deal with; a syntax to
learn if no GUI is provided; understanding the links between the code and the database
requires some effort; can become out of sync with the code
• Advantages of attributes/annotations: everything at hand at code-level; the mapping is
obvious since directly present on classes and class members; can be used to generate
external mapping files using reflection if needed; if the mapping tool isn't used anymore,
they are ignored
• Disadvantages of attributes/annotations: the code is "polluted"; the code depends on a
41
specific mapping framework
● Support for disconnected mode: fill objects from a database, close the connection, the session,
create/update/delete some objects, and apply this modifications back to the database later.
● Interceptors and delegation mechanisms: Strategy to be able to react when the handling of
the persistence happens (eg. to be able to log what happens)
● Support for stored procedures: The advantages of stored procedures compared to dynamic
SQL queries make for a hot debate, but it is better to have the choice.
● constraints handling: Ability to specify constraints between objects and on properties (OCL -
Object Constraint Language). This can avoid having to wait for the data to reach the database
before being validated.
● Filtering objects in memory: Ability to filter objects in memory without having new queries
executed on the database.
● Deferred operations cache: Be able to defer the updates on the database, and apply them at a
given time using a specific method call, instead of having them systematically applied
immediately.
As you can see, the criteria are numerous! While choosing an ORM tool one should start by defining
which are critical for him (MUST HAVE) and which are less important (NICE TO HAVE).
3.3. Chosen ORM candidates:

Now that the comparison analysis criteria for Object-relational mapping has been identified and
defined, it needs to be tested on real software tools. The following table lists the chosen candidates for
comparison analysis. An introduction is given on these tools in the following sub sections.
42
Tool Version used Category Description

JDBC 4.0 Free - JDBC is an API that
implemented in Java SE 6 The Java Development Kit provides universal
(Java 6.0 will include a (JDK) is free to download and database access for the
number of Java Database use for commercial Java programming
Connectivity enhancements programming
collectively known as
language.
JDBC 4.0) http://java.sun.com/
Hibernate 3.2 Open source–GNU LGPL Hibernate is an open
requires JDK 1.4 or newer Free to download and source object/relational
free to use for both development mapping tool for Java
and production deployments. http://www.hibernate.org/
JPOX 1.2.2 Free - JPOX is a free and fully

(Java persistent objects) JDO1, JDO2, JDO2.1 and Apache Public License compliant
JPA1 compliant implementation of the
JDO
http://www.jpox.org/
Db40 7.2 Open source – GPL Db4o is a high-

(Database for objects) for Java Free when licensed under performance,
ODBMS GPL. embeddedable open
source object database.
http://www.db4o.com/
Table 3: Chosen ORM tools for comparative analysis
3.3.1. JDBC:
JDBC is an API that provides universal database access for the Java programming language. JDBC is
the trademarked name and is not an acronym. But JDBC is often thought of as standing for "Java
Database Connectivity." The current version of JDBC API is JDBC 4.0 API implemented in Java SE 6.
It includes two packages:
• JDBC 4.0 Core API - The java.sql package, which is distributed as part of Java SE 6. The core
API is good enough for normal database applications.
• JDBC 4.0 Standard Extension API - The javax.sql package, which is distributed as part of Java
SE 6. The standard extension API, javax.sql, can also be downloaded from
http://java.sun.com/products/jdbc. It is required for applications that uses connection pooling,
43
distributed transactions, Java Naming and Directory Interface (JNDI), and RowSet API.
The specification of JDBC 4.0 API is documented in JSR (Java Specification Request) 221 maintained
by JCP (Java Community Process).
In order to use JDBC to connect Java applications to a specific database server, you need to have a
JDBC driver that supports JDBC API for that database server. For example, Microsoft JDBC Driver
allows you to access Microsoft SQL Server through the JDBC API.
As shown in the following figure the JDBC Architecture consists of two layers: the JDBC API, which
provides the application-to-JDBC Manager connection, and the JDBC Driver API, which supports the
JDBC Manager-to-Driver Connection. [JJO08]
Illustration 3: JDBC Architecture
3.3.2. Hibernate:
Hibernate is an open source Object-relational mapping tool for Java. Hibernate lets you develop
persistent classes following common Java idiom - including association, inheritance, polymorphism,
composition and the Java collections framework.
Hibernate not only takes care of the mapping from Java classes to database tables (and from
44
Java data types to SQL data types), but also provides data query and retrieval facilities and can
significantly reduce development time otherwise spent with manual data handling in SQL and JDBC.
Hibernates goal is to relieve the developer from 95 percent of common data persistence related
programming tasks. Hibernate is Free Software. The LGPL license is sufficiently flexible to allow the
use of Hibernate in both open source and commercial projects. Hibernate is available for download at
http://www.hibernate.org/.
The following diagram describes the high level architecture of hibernate: [HD08]
Illustration 4: Hibernate Architecture
The above diagram shows that Hibernate is using the database and configuration data to provide
persistence services (and persistent objects) to the application
To use Hibernate, it is required to create Java classes that represents the table in the database
and then map the instance variable in the class with the columns in the database. Then Hibernate can be
used to perform operations on the database like select, insert, update and delete the records in the table.
45
Hibernate automatically creates the query to perform these operations.
3.3.3. JPOX (Java persistent objects) JDO:
The Java™ Data Objects (JDO) specification introduced by the Java Community Process (JCP) is a
framework which persists plain Java objects to a datastore such as an RDBMS. JDO facilitates rapid
development with an open standard and can be used in nearly any Java environment. Java Persistent
Objects (JPOX) is a free and fully compliant implementation of the JDO1, JDO2, JDO2.1 and JPA1
specifications, providing transparent persistence of Java objects. It supports persistence to all of the
major RDBMS on the market today, persistence to the DB4O object data store, supporting all of the
main Object-Relational Mapping (ORM) patterns demanded by today's applications, allows querying
using either JDOQL, SQL, or JPQL, and comes with its own byte-code enhancer. JPOX is available
under the Open Source Apache 2 license.
The first thing to do when designing the datastore layer using JPOX is to define your classes to
be persisted (aka your "model"). You define this with either XML Metadata or annotations (or a mix of
both). As well as defining which classes and which fields of these classes are persisted you also have to
specify how the "identity" of each object is defined.
JPOX provides a high performance persistence mechanism by utilizing bytecode enhancement

to provide rapid detection of changes to persisted objects, allowing optimization not available using
reflection based tools. The following figure shows high level JPOX architecture. [JPOXD08]
46
Illustration 5: JPOX Architecture
JPOX is architected to provide an extensible persistence framework for heterogeneous datastores.

Outofthebox JPOX provides support for all major RDBMS on the market, together with DB4O. All
JPOX jars are OSGi bundles allowing deployment in J2SE environments, J2EE environments and
OSGi environments. JPOX provides a host of extension points allowing users to utilize the JPOX
persistence mechanism with their own corporate components, defining customized persistence of own
Java types, and generally not be limited in development.
3.3.4. Db4o (Database for objects) ODBMS:
db4o (database for objects) is a high-performance, embeddedable open source object database for Java
and .NET developers. db4o is designed to be embedded in clients or other software components
completely invisible to the end user. Thus, db4o needs no separate installation mechanism, but comes
47
as just one easily deployable library with a very low footprint of some 400KB. db4o supports Java's
JDK 1.1.x through 5.0 and runs on J2EE and J2SE.
Rather than using string-based APIs (such as SQL, OQL, JDOQL, EJBQL, and SODA), db40
uses Native Queries which allow developers to simply use the programming language itself (e.g., Java)
to access the database and thus avoid a constant, productivity-reducing context switch between
programming language and data access API.
The full version of db4o is available under two licenses (dual license): the open source, GPL,
which enables easy download, evaluation, and use in GPL compliant projects; and a commercial
runtime license with indemnification from db4objects for product development companies that wish to
embed db4o into their commercial, non-GPL products. The following picture gives a glimpse of db40
approach to storing objects. Unlike relational databases, db4o eliminates the object-relational mismatch
entirely. [DB4O08]
Illustration 6: RDBMS - db4o's Object Database
db4o have No Impedance Mismatch. The application's class hierarchy and object relationships
themselves define the database schema.
3.4. Chosen example for ORM candidates implementation:

In this section I will briefly describe the example chosen for ORM implementations. I chose a Banking
application to implement and analyse ORM candidates. This Banking application has two roles, an
Administrator and a User. I chose it as ATM banking application, especially because the Administrator
part of it can be modelled as web application and User part of it can be modelled as distributed Java
48
application. I implemented the persistence layer for the application using all the four technologies
described in the above sections. In the following chapter (chapter 4) you will see details of each
implementation.
The application’s high-level architecture is shown in figure 3.5. This diagram shows the
application’s main components and its actors. It has the standard three-layer architecture consisting of
the web-based/GUI presentation, business, and database access layers. The application stores its data in
a relational database for first three implementations and in Object-oriented database for fourth
implementation.
Illustration 7: High level architecture of

ATM Banking application
49
The application’s persistence layer is responsible for accessing the database. The design of the
presentation layer and business layer are not part of this thesis, so I am going to focus on the design of
the persistence layer. In the following figure 3.6 you see the persistence layer as two subsystems that
form a layered structure. The upper layer, called the Persistent objects layer, encapsulates the concepts
of object-orientation while the lower layer, called the Database Handler, offers a high level interface on
top of Database (RDBMS / ODBMS).
Illustration 8: High level architecture of Persistence layer
The ATM Banking application is completely elaborated (requirements, use cases and EER diagram) in
Appendix A.
Tools used for implementation:

As the aim of this thesis is to compare and analyse ORM's, the persistence layer is implemented in all
four technologies, ORM and ODBMS. The following tools are used in implementation.
50
Tool Version used Category Description

Netbeans 6.0.1 Free – open source A free, open-source IDE for software
developers.
http://www.netbeans.org/
Apache 10.3.2.1 Free - Apache Apache Derby, an Apache DB subproject, is
Derby License, Version 2.0 an open source relational database
implemented entirely in Java.
http://db.apache.org/derby/
JUnit 4.1 Free – open source JUnit is a simple Java testing framework to
write tests for Java applications.
http://www.junit.org/
JMeter 2.3.1 Free - Apache Apache JMeter is a 100% pure Java

License, Version 2.0 desktop application designed to load test
functional behavior and measure
performance.
http://jakarta.apache.org/jmeter/
Java JDK 6 Free - GPL The Java SE Development Kit (JDK)

includes the Java Runtime Environment
(JRE) and command-line development tools
that are useful for developing applications.
http://java.sun.com/
Table 4: Tools used for implementation
In the following chapter (chapter 4 ) you will see details of each ORM Implementation, later in
chapter 5 the results of comparative analysis are elaborated.
51
Chapter 4. ORM Implementations
In this chapter you will see details of each ORM candidate implementation of example application. As
you read along the sections you will sometimes find that I am not explaining the points stated in
previous implementation, this is done intentionally to avoid most of the redundant steps and words.
This chapter can serve as high level tutorial for the ORM candidates.
4.1. JDBC Implementation:

In this section I am going to show you the step by step process I followed to develop persistence layer
for the example application using JDBC and Derby database. I designed database schema for the Use
case requirements and written Java code to persist objects using JDBC API.
Step 1 : Database installation and schema definition:

As I am using Netbeans6.0.1, the Sun Java System Application Server is registered in NetBeans IDE
and the Java DB (which is based on the Apache Derby database) is already registered in IDE. Once a
connection is made, i can begin working with the database in the IDE, it allows to create tables,
populate them with data, run SQL queries, and more [LGDN08]. I defined database schema using IDE,
this schema follows the EER I developed for the Use case specified in Appendix A. Please see EER
diagram.
Step 2 : Domain classes:
As per retirements stated in Appendix A I designed domain classes as below (these are under
52
ORM Implementations
orm.jdbcimpl.perobj package in source code).

Administrator
Customer
Transactions
PendingDeposits &
Atm
these objects are "Plain Old Java Objects" (POJO's) with no persistence code.
Step 3 : Persistence code:
After step 2, it is time to write persistence code for the domain objects. The following class diagram
shows the persistence layer I developed using JDBC.
53
ORM Implementations
Illustration 9: JDBC implementation - Persistence layer class diagram
The AdminTransactionHandler is responsible for administrator related Use case persistence activities.
This class uses AdminAuthenticator for authentication of a adminstrator and DatabaseManager class
for database connection and basic database operations. The TransactionsHandler class is responsible
54
ORM Implementations
for user related Use case persistence activities. This class uses UserAuthenticator for authentication of
a user and DatabaseManager class for database connection and basic database operations.
As everybody know how verbose JDBC code will be, I am not going to explain much about code, but
to give you glimpse of boiler plate code, below I gave a section from AdminTransactionHandler
addCustomer method.
public class AdminTransactionHandler {

private DatabaseManager dbMgr;
......
/* method which stores new customer object*/
public boolean addCustomer(Customer $customer) throws InSufficientBalanceException {
if ($customer.getAccountBalance() >= 100) {

boolean status = false;
//generating account number.
String strGenAccNo = "select max(accountNo)+1 from SAVINGSACCOUNT";
$customer.setAccountNo(dbMgr.executeQueryString(strGenAccNo));
......
As part of code you must set each attribute from domain class to each attribute of database table
String strAccQuery = "insert into SavingsAccount values('"
+ $customer.getAccountNo() + "','" + $customer.getName()
+ "'," + $customer.getAccountBalance() + ",default,'"
+ $customer.getAddress() + "','O','" + strDOB + "')";
int noOfRows = dbMgr.updateQuery(strAccQuery);
......
The following code is from DatabaseManager class referred above as dbMgr object.
public int updateQuery(String query) {
Statement stmt = null;
int noOfRowsUpdated = 0;
try {
stmt = conn.createStatement();
try {
noOfRowsUpdated = stmt.executeUpdate(query);
55
ORM Implementations
} catch (SQLException sqle) {

sqle.printStackTrace();
}
} catch (SQLException sqle) {
sqle.printStackTrace();
}
return noOfRowsUpdated;
}
......
return status;
}
......
}
}
This code is just part of one method which persists a Customer object to database. Please see source
code for complete view of persistence layer code.
To handle the various application (Use case) specific errors I defined following exceptions. These
exception classes will be used for all the four implementations, so I won't mention them again in next
sections.
56
ORM Implementations
Illustration 10: Exceptions class diagram
57
ORM Implementations
Step 4: Testing and execution times:

In this step I implemented test cases for all components developed during above steps using Junit. I
noted execution time of each unit test of user and administrator modules. These execution times can be
used later in next chapter for comparative performance analysis.
4.2. Hibernate Implementation:

In this section I provide step by step instructions and process I followed to develop persistence layer for
the example application using Hibernate 3.2. I used both native SQL and HQL queries for this
implementation. HQL (Hibernate Query Language) is designed as a "minimal" object-oriented
extension to SQL. HQL provides an elegant bridge between the object and relational worlds.
[CHTRI08] [JPHBK08]
Step 1: Project library:

As I am working with Netbeans IDE, created a new Java project in the IDE and added the following
Hibernate libraries to the project library.
Antlr-2.7.6.jar
asm.jar
asm-attrs.jars
c3p0.jar
cglib-2.1.3.jar
commons-collections-2.1.1.jar
commons-logging-1.0.4.jar
dom4j-1.6.1.jar
hibernate3.jar
jta.jar
log4j-1.2.11.jar
derbyclient.jar
The libraries are from the Hibernate distribution, most of them required for a typical Hibernate project.
The derbyclient.jar is from Apache Derby distribution.
For Database installation and schema definition I followed the same step as in step 1 of JDBC
implementation so I wouldn't mention in detail again.
58
ORM Implementations
As Hibernate uses persistent classes that are mapped to database tables, it is obvious to follow this step
and define the domain classes based on business domain. I used the domain classes defined in 4.1 with
few modification. To make things a bit more interesting, i have replaced Customer class with
SavingsAccount class and AtmCard class. AtmCard is a subclass of SavingsAccount and adds two extra
fields on top of the ones it inherits. Please see Domain class diagram in Appendix A. I have defined an
id attribute in each of these classes which allows the application to access the database identity-the
primary key value of the persistent object.
Step 3: Mapping domain classes to database schema:

Hibernate needs some information about exactly how the domain classes be persistent, in other words
hibernate needs to know how instances of each class are supposed to be stored and loaded. This
metadata can be written into an XML mapping document, which defines, among other things, how
properties of the domain classes map to columns of database tables. Following is a section of mapping
file of SavingsAccount class.
<hibernate-mapping>
<class name="orm.hibernate.perobj.SavingsAccount" table="SAVINGSACCOUNT">

<id
name="savingsAccount_id”
column="SAVINGSACCOUNT_ID">
<generator class="increment" />
</id>

<property
name="accountNo"
type="java.lang.String"
column="ACCOUNTNO"
not-null="true" />
.....
59
ORM Implementations
.....
<set name="transactions" cascade="all,delete-orphan" lazy="false"
inverse="true">
<key column="SAVINGSACCOUNT_ID" not-null="true" />
<one-to-many class="orm.hibernate.perobj.Transactions" />
</set>
.....
</class>
</hibernate-mapping>
I created a file named SavingsAccount.hbm.xml with the content shown above, and placed it next to
SavingsAccount.java file in the source package. Same is done for all other domain classes.
Step 4: CRUD operations:
After above three steps, Hibernate has enough information to generate all the SQL statements needed to
insert, update, delete, and retrieve instances of domain classes. I wrote a generic class which performs
all CRUD operations. This class is responsible for all database related operations. The below section of
code briefly explains how this class is organized. Please see the source code for complete file.
public class HibernateTransactionHandler {

//initialized fields
Session session = null;
.....
/* method which stores new objects*/
public Object create(Object object) {
.....
// store object
session.save(object);
.....
}
/* method which retrieves all objects of a class*/

The following method uses a HQL query.
60
ORM Implementations
public List all(String className) {

.....
// retrieveAllobjects
String QUERY = "from " + className + " objects";
Query query = session.createQuery(QUERY);
objects = query.list();
.....
}
/* method which retrieves an object by specified SQL/HQL query statement*/

public Object retreiveObject(final String query) {
.....
retrievedObject = session.createQuery(query).uniqueResult();
.....
}
/* method which updates an object*/
public boolean update(Object object) {
.....
session.update(object); // updating object
.....
}
/* method which deletes an object*/
public boolean delete(Object object) {
.....
session.delete(object);
.....
}
}
Step 5: Hibernate configuration file:

For Hibernate provided connection pooling and transaction management it is required to provide a
configuration file to setup environment. This configuration file must bear default name
hibernate.cfg.xml and be placed directly in the source directory of project, outside of any package. This
61
ORM Implementations
way, it will end up in the root of classpath after compilation, and Hibernate will find it automatically.
Following is the section of configuration file for this implementation.
<hibernate-configuration>
<session-factory>

<property name="hibernate.connection.driver_class">org.apache.derby.jdbc.ClientDriver</property>
<property name="hibernate.connection.url">jdbc:derby://localhost:1527/ormhibernate</property>
<property name="hibernate.connection.username">ormhibernate</property>
<property name="hibernate.connection.password">ormhibernate</property>


<property name="dialect">org.hibernate.dialect.DerbyDialect</property>
.....

<mapping resource="orm/hibernate/perobj/Administrator.hbm.xml"/>
.....
</session-factory>
</hibernate-configuration>
Step 6: Persistence Layer:
After above steps and testing basic CRUD operations I wrote database handlers for each type of
domain class object to handle CRUD operations. These handlers mainly supply the specific class and
attribute related data to the generic CRUD class developed in step 3.
After successfully writing CRUD operations for each type of object in domain model, I
developed Use case specific operations for the persistence layer. In the following class diagram you see
the classes developed in this step and their usage of generic CRUD component
HibernateTransactionHandler stated in step 4.
62
ORM Implementations
Illustration 11: Hibernate implementation - Persistence layer class diagram
63
ORM Implementations
used later in next chapter for comparative analysis.
As I implemented persistence layer with Hibernate I am impressed by it. It appears mature and robust.
It's easy to use and the documentation is very good. I actually hand written Java code and defined
database schema my self but Hibernate have tools which by simply writing a simple xml document, can
generate java code and sql code. Or it can work with a legacy database and legacy objects, the xml
document links the two together. The simplicity of the design, and how well it stays decoupled from
application logic, are some of the reasons why I like it so much.
4.3. JPOX JDO Implementation:

In this section I am going briefly explain the steps involved in developing the persistence layer using
JPOX JDO. The JDO process is quite straightforward [JPT08]. As I explained about my working in
Netbeans IDE in previous sections, it is assumed that I follow the same procedure for basic project
settings. In this section you see only JPOX JDO related development steps.
Step 1: Domain classes:

These are same as in previous section. The only JDO constraint on any Java class that needs
persisting is that it has a default constructor (this can be private, and will actually be added by the
JPOX Enhancer if not added by developer).
Step 2: Persistence definition for domain classes:

After getting ready with domain classes, now I need to define how the classes should be persisted, in
64
ORM Implementations
terms of which fields are persisted etc. This is done by writing a Meta-Data persistence definition for
each class in a JDO MetaData file. There are several ways to do this, including using XDoclet, however
the most common way is to write the Meta-Data file manually. Below you see the part of the metadata
file.
<jdo>
<package name="orm.JPOXjdo.perobj">
<class name="SavingsAccount" identity-type="application"
table="SAVINGSACCOUNT" detachable="true">
<inheritance strategy="new-table"/>
<field name="savingsAccount_id" primary-key="true" value-strategy="max">
<column name="SAVINGSACCOUNT_ID" jdbc- type="BIGINT"/>
</field>
<field name="accountNo">
<column name="ACCOUNTNO" length="10" jdbc-type="VARCHAR"/>
</field>
.....
</class>
.....
</package>
</jdo>
With JDO there are various options as far as where these MetaData files are placed in the file structure,
and whether they refer to a single class, or multiple classes in a package. In this implementation, i have
all classes specified in the same file package.jdo, and placed directly in the source directory of project.
Step 3: Instrument/Enhance domain classes:

JDO relies on the domain classes to persist being PersistenceCapable. That is, they need to implement
this Java interface. JPOX JDO provides its own byte-code enhancer for instrumenting/enhancing the
persistent classes for use by any JDO implementation. We need to obtain the Enhancer JAR (as well as
the SUN JDO JAR) to use this. The following jar's are added to the project library.
jdo2-api-2.1.jar
jpox-core-1.2.2.jar
jpox-enhancer-1.2.2.jar
log4j-1.2.15.jar
65
ORM Implementations
bcel-5.2.jar
derby.jar
derbyclient.jar
jpox-rdbms-1.2.2.jar
The first thing to do is compile domain classes. For enhancing, Netbeans provides a convenient way of
integrating this procedure into the build process without the need for any additional tool or plugin. This
is possible because NetBeans stores project information in .properties files and relies on Ant for the
build process. Class enhancement thus becomes a simple matter of adding a new task to the existing
build.xml generated by NetBeans [JPN08]. Override the -post-compile task/target with the following
Ant instructions.
<target name="-post-compile">
<echo message="Enhancing the MODULE files"/>
<copy todir="${build.classes.dir}">
<fileset dir="${src.dir}"
includes="**/*.jdo,**/*.properties,**/*.dtd,**/*.xml"/>
</copy>
<path id="module.enhancer.classpath">
<fileset dir="lib" casesensitive="yes">
<include name="*.jar"/>
</fileset>
<pathelement path="${javac.classpath}"/>
<pathelement location="${build.classes.dir}"/>
</path>
<taskdef name="jpoxenhancer"
classpathref="module.enhancer.classpath"
classname="org.jpox.enhancer.tools.EnhancerTask" />
<jpoxenhancer classpathref="module.enhancer.classpath" enhancerName="BCEL"
dir="${src.dir}"
failonerror="true"
fork="true"
verbose="true">
<jvmarg line="-Dlog4j.configuration=${log4j.properties}"/>
</jpoxenhancer>
</target>
66
ORM Implementations
This target is the most convenient for enhancing classes because it occurs just after all classes have
been compiled and is called in any case, whether the project is being built, tested or deployed. This
ensures that classes are always enhanced. By “Clean and Build” the project give the following output.
JPOX Enhancer : Using ClassEnhancer "BCEL" for API "JDO"
JPOX Enhancer : Input Files

>> C:\Thesis\19-04-2008\OrmJPOXjdoImplimentation\src\package.jdo
ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.SavingsAccount

ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.AtmCard
ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.Administrator
ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.Atm
ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.Transactions
ENHANCED (PersistenceCapable) : orm.JPOXjdo.perobj.PendingDeposits
JPOX Enhancer completed with success for 6 classes. Timings : input=828 ms, enhance=391 ms,
total=1219 ms. Consult the log for full details
Now the classes are enhanced and ready for persistence.
Step 4: JPOX configuration file:
Java Persistent Objects JDO (JPOX) allows a level of runtime configuration. This configuration is
typically specified in a jpox.properties file, follwing is the section of the file I specified
javax.jdo.option.ConnectionDriverName=org.apache.derby.jdbc.ClientDriver
javax.jdo.option.ConnectionURL=jdbc:derby://localhost:1527/ormJPOXjdo
javax.jdo.option.ConnectionUserName=ormjpoxjdo
javax.jdo.option.ConnectionPassword=ormjpoxjdo
Above it specified that, I have a Derby datastore, with the database called "ormJPOXjdo".
67
ORM Implementations
After above four steps, JPOX JDO has enough information to generate all the SQL statements needed
to insert, update, delete, and retrieve instances of domain classes. I wrote a generic class which
performs all CRUD operations. This class is responsible for all database related operations. The below
section of code briefly explains how this class is organized. Please see the source code for complete
file.
public class JPoxJDO {

private PersistenceManager pm;
.....
The initial step is to obtain access to a PersistenceManager, which is done as follows

PersistenceManagerFactory pmf = JDOHelper.getPersistenceManagerFactory("jpox.properties");
PersistenceManager pm = pmf.getPersistenceManager();
So PersistenceManagerFactory using the file jpox.properties is being created. This will contain all
properties necessary for our persistence usage.
Now that the application has a PersistenceManager it can persist objects. This is performed as follows

.....
// store object
pm.makePersistent(object);
.....
}

public List all(Class className) {
Extent extent = null;
.....
68
ORM Implementations
.....
extent = pm.getExtent(className, true);
for (Iterator i = extent.iterator(); i.hasNext();) {
Object object = (Object) (i.next());
objects.add(object);
}
.....
return objects;
}
/* method which retrieves an object by id*/

public Object retreiveObject(Class className, long id) {
.....
object = pm.getObjectById(className, Long.valueOf(id));
pm.detachCopy(object);
.....
return object;
}

.....
pm.makePersistent(object);
.....
}

.....
pm.deletePersistent(object);
.....
}
Clearly you can perform a large range of operations on objects. It is as simple as shown above.
69
ORM Implementations
Step 6: Persistence Layer:
After above steps and testing basic CRUD operations I wrote database handlers for each type of
domain class object to handle CRUD operations. These handlers mainly supply the specific class and
attribute related data to the generic CRUD class developed in step 5.
After successfully writing CRUD operations for each type of object in domain model, I
developed Use case specific operations for the persistence layer. In the following class diagram you see
the classes developed in this step and their usage of generic CRUD component JPoxJDO stated in step
4.
70
ORM Implementations
Illustration 12: JPOX JDO implementation - Persistence layer class diagram
71
ORM Implementations
As I implemented persistence layer with JPOX JDO I was impressed by it in beginning, but as I
continued with implementation I felt resources be limited. JPOX has active user forum and good online
documentation, but my point is sometimes when you developing something you wish to get answers as
soon as you type a key word in google, this is not so good for JPOX. Mostly, the only site which you
get redirected to is to JPOX official site. Otherwise, everything is perfect with JPOX JDO.
4.4. Db4o Implementation:

In this section I am going to show you the step by step process I followed to develop persistence layer
for the example application using db40 ODBMS. It is very simple to create a database and store objects
using db4o Object database. I used two query methods: Query-By-Example (QBE) and the more
flexible S.O.D.A query API of db4o. [DBT08] [JPDB04]
Step 1 : Db4o installation:
Added db4o-7.2-java5.jar to CLASSPATH of the project and db4o is installed, very simple.
Designed domain/model classes, these are actually same for all four implementations.
As per retirements stated in Appendix A I designed six domain classes as below (these are
under orm.db4o.perobj package in source code). Please see Domain class diagram in Appendix A.
72
ORM Implementations
Administrator.java
SavingsAccount.java
AtmCard.java
Transactions.java
PendingDeposits.java &
Atm.java
The six classes in the example represent administrator and User of a Banking Atm system.
Administrator and SavingsAccount are the two classes which represent administrator and user of the
system. To make things a bit more interesting, i also have a AtmCard class. AtmCard is a subclass of
SavingsAccount and adds two extra fields on top of the ones it inherits. SavingsAccount has an attribute
that is a list of Transactions objects and also has an attribute that is a list of PendingDeposits.
PendingDeposits and Transactions have an attribute of Atm and AtmCard objects. Administrator,
SavingsAccount, AtmCard, Transactions, PendingDeposits and Atm objects are "Plain Old Java
Objects" with no persistence code. No unique key attributes are required as an object database
automatically stores objects with unique object identifiers (OIDs).
After step 2, it is time for their persistence. I wrote a generic class which performs all CRUD
operations. This class is responsible for all database related operations. Following section of code
briefly explains how this class is organized. Please see the source code for complete file.
public class Db40Persistence {

private ObjectContainer db = null;
.....
// accessDb4o (open or create database file)

setDb(Db4o.openFile(config, DB4OFILENAME));
73
ORM Implementations

.....
// store object
getDb().store(object);
.....
}
The following two methods uses a SODA query. The SODA query API is db4o's low level querying
API, allowing direct access to nodes of query graphs.
public ObjectSet all(Class className) {

....
// retrieveAllobjects
Query query = getDb().query();
query.constrain(className);
result = query.execute();
....
}
/* method which retrieves an object of a class by descending to its constrain field and constraining
this with the respective candidate String.*/
public Object retreiveObject(Class className, String descend, Long constrain) {

....
Query query = getDb().query();
query.constrain(className);
query.descend(descend).constrain(constrain);
ObjectSet result = query.execute();
object = result.next();
....
74
ORM Implementations

....
getDb().store(object);
....
}
/* method which deletes an object*/

....
getDb().delete(object);
....
}
As you see in the above code it is very easy to write CRUD operations for Db4o.
Step 4: Domain objects Handlers for CRUD operations:
After step 3, I wrote database handlers for each type of domain class object to handle CRUD
operations. These handlers mainly supply the specific class and attribute related data to the generic
CRUD class developed in step 3.
Step 5: Administrator and User specific use case operations (Persistence layer):
After successfully writing CRUD operations for each type of object in domain model, in this
step I developed Use case specific operations for the persistence layer. In the following class diagram
you see the classes developed in step 4 and this step and their usage of generic CRUD component
Db40Persistence stated in step 3.
75
ORM Implementations
Illustration 13: Db4o implementation - Persistence layer class diagram
76
ORM Implementations
In this section I showed how a small footprint, embeddable object database offers a very simple,
compact route to object persistence. db4o is now an open source object database that offers a range of
attractive features and supports both Java and .NET. The simplicity of installation and use as well as the
lack of an impedance mismatch between object and data models make db4o very useful in a range of
business and educational applications.
77
ORM Implementations
Chapter 5. Comparative analysis results:
This chapter shows the complete comparative analysis of ORM's for Java based on the criteria formed
in chapter.3. The study is done based on literature available on the topic ORM and the implementations
of each ORM candidate tools, as explained in chapter.4. The comparison is done in tabular form for
easy legibility. In section 5.1 is shown comparison of general criteria, followed by comparison of ORM
specific criteria in section 5.2, comparison of performance in section 5.3. Finally in section 5.4
recommendations are given for choosing ORM tool and a conclusion is drawn with recommendations
for further research.
5.1. Comparison of general criteria:
In this section is shown comparison of general criteria for ORM based on the criteria developed in
section 3.2.1.
78
Comparative analysis results:
Tool -> using

criteria JDBC Hibernate JPOX JDO ODBMS (db4o)
Complexity Simple, all Java Less code, It relieves JDO is all about Fewer lines of code,
(or) programmers know programmer from simplicity and JPOX less complexity to
simplicity how to program in manual handling of is on the cutting edge manage.
JDBC. persistent data. Has of the available JDO
steep learning curve. implementations.
Ease of use, Yes easy to use, One of the reasons for anyone can run their helps you to get things
time to be up JDBC 4 has a strong Hibernates popularity first JPOX example in done in less time with
and running focus on ease-of-use is its ease of use. up just a couple of less trouble. Has ease
and programmer and running in ten minutes using sample of deployment.
productivity. minutes or less . JPOX app.
Flexibility Not very flexible in Hibernate provides flexibility for db4o has the
designing Object tremendous flexibility different people to flexibility to fit in
oriented concepts. for mapping O/R. develop the data-tier architectures, which
utilizing their own aim to achieve better
skills to the full productivity in object-
without having to oriented software
learn totally new development."
concepts.
Documentati Has very good One of the reasons for provides extensive Has good
on documentation. Hibernates popularity documentation. documentation with
is its documentation. Extensive examples.
Maturity or First released in The first version was is a fully compliant created in 2000 and
Longevity 1997, current version released in 2001, implementation of the first shipped in 2001.
is 4.0 released in became very popular, JDO1/JDO2 launched in 2004 as
2006. distributed as has won a Jolt Award specifications. JPOX commercial. Today,
part of Java Se 6, in 2005, present project was started in db4objects has
documented in JSR version is 3.2.6.ga March 2003 with first become one of the
221 and maintained released on February release 1.0 in July hottest technology
by JCP. 8, 2008. Has very 2004, 1.1 in May innovators in Silicon
active community. 2006, and latest 1.2 in Valley.
March 2008. JPOX
has very active
community.
Frequency of Regular updates are Has rapid release Regular updates are Regular updates are
the updates, available. schedule, regular file available. available.
bug fixes, releases (even a few
evolutions days from one version
to the next).
Support Has Sun forum and Has very active user Yes, has online world's largest user
(forums, many more. forum and also has support community community for
community) commercial support, also offers ODBMS technology,
training, and professional paid with 35000 registered
79
consulting. support (training and peers.

consulting).
Vendor's Very much stable, Hibernate has Has good reputation Has good reputation
reputation distributed as part of excellent reputation and stable. and stability.
and stability JDK. and stability.
Source code Yes Yes, source code Yes, source code Yes
provided or available. available.
not
Support for Yes, Java has Yes, cross-platform Multi platform is a multiplatform
multiple MultiPlatform (JVM) Windows/Linux/Mac solution, also it
platforms Support. OS/BSD/Solaris and supports Java and
supports RDBMS, .NET
DB4O, LDAP.
Price Free - Free - Free - Free -
The Java Open source–GNU Apache Public
Open source – GPL
Development Kit LGPL License Free when licensed
(JDK) is free toFree to download and under GPL.
download and usefree to use for both
for commercial development and
programming production
deployments.
Performance A whole section is dedicated to compare performance, please see section 5.3 Comparison
of performance.
Table 5: Comparison of general criteria
5.2. Comparison of ORM specific criteria:
In this section is shown comparison of ORM specific criteria for ORM based on the criteria developed
in section 3.2.2.
80
Tool -> using

criteria JDBC Hibernate JPOX JDO ODBMS (db4o)
Basic features
Transparent developer need to provides transparent provides transparent the manipulation and
Persistence write lines of code persistence. persistence. traversal of persistent
explicitly to map (developer does not objects is performed
database tables need to write code fully compliant directly by Java
tuples to explicitly to map implementation of (OOP) in the same
application objects database tables the JDO 1.0 and 2.0 manner as in-
during interaction tuples to application specifications memory, non-
with RDBMS. objects during persistent objects.
interaction with
RDBMS)
Inheritance does not handle Yes, can handle Yes, have choices to Inheritance is a core
inheritance. inheritance in handle inheritance. feature, no mismatch
number of ways. exists.
(developer has to New-table
write code to map table per class (do not have to do
an object model's hierarchy subclass-table anything special with
data representation inherited classes)
to a relational data table per subclass superclass-table
model and its
corresponding table per concrete
database schema) class
Relations Does not support resolved directly by Supports relations. There are no tables.
table relations. means of 1-1, 1-N, N-1 and Can handle 1-N, M-N
associations 1-1, 1-N M-N. relations with List.
N-1, M-N. Supports both
Supports both unidirectional and The application's
unidirectional and bidirectional class hierarchy and
bidirectional relations. object relationships
associations. themselves define the
database schema.
Transactions Can use disable Uses Session and Uses JDO provides a transaction
auto-commit mode Transaction classes. Transaction and mechanism.
and PersistenceManager
setTransactionI every SQL classes. Uses ObjectContainer
solation for statement, be it class.
Connection. queries or DML, has the
to execute inside a PersistenceManager you always work
database is used for all JPOX inside a transaction,
Transaction. transactions i.e., with
81
ObjectContainer.
Aggregates Supports all SQL Supports avg(), Supports avg(), Not supported.
aggregates. sum(), min(), sum(), min(),
max() ,count(). max() ,count(). For statistical tabular
data RDBMS is best.
Grouping Supports SQL HQL supports Group JDOQL supports Not supported.
Group By By Clause. group by Clause.
Extended features
Supported There are currently Many, please see Excellent support for -Not applicable-
databases 221 JDBC drivers the vast majority of Is a database itself.
available from http://www.hibernate RDBMS available
different vendors. .org/80.html on the market today.
[JDAA08]
Query Supports only Supports native SQL Supports three query supplies three
language native Structured statements and languages querying systems,
query language provides a powerful
(SQL) query language SQL Query-By-Example
Hibernate Query JDOQL (QBE)
Language, HQL JPOXQL
(independent from Native Queries (NQ),
type of database) that http://www.jpox.org/ and
is expressed in a docs/1_1/query.html
familiar SQL like the SODA API.
syntax and includes
full support for
polymorphic queries.
Flexibility
Customizatio Developer has to HQL provides JDOQL provides SODA is useful for
n of queries find out the custom SQL queries. custom SQL queries. dynamic generation
efficient way to of queries
access database, i.e selects an effective
to select effective way to perform a
query from a database
number of queries manipulation task for
to perform same an application.
task.
Support for Yes. Supports both inner Supports both inner -Not applicable-
SQL joins Developer must and outer joins and outer joins
write code.
Concurrency Has transaction Has optimistic supports 3 optimistic Supports only
management Isolation Levels, concurrency control locking strategies. optimistic locking.
82
which control with automatic Version-number,

concurrency: versioning and Time date-time, none.
Stamping.
TRANSACTION_NONE Supports pessimistic
TRANSACTION_READ_C
OMMITTED Supports pessimistic locking.
TRANSACTION_READ_U locking.
NCOMMITTED
TRANSACTION_REPEAT org.jpox.useUpdate
ABLE_READ Lock
TRANSACTION_SERIALI
ZABLE
Automatic
versioning and
Time Stamping has
to be added by the
developer.
Data type Supports all data Supports all data Supports all data Have problems with
support for types for supported types for supported types for supported java.sql.Timestamp.
RDBMS databases. databases databases
Supports almost all of
except some issues except some issues java.sql datatypes.
with some databases with some databases
like, Problems with like, MS SQL 2000
the use of index for does not keep
the 'bigint' type in accuracy on
PostgreSQL, please datetime datatypes.
see Please see
http://www.hibernate http://www.jpox.org/
.org/80.html docs/1_1/rdbms.htm
l
Single class Developer must Using the <join> JDO allows db4o stores objects as
to multiple write code to element, it is persistence of fields objects, not in tables.
tables achieve this. possible to map of a class into
properties of one secondary tables.
class to several [JPOXD08]
tables.
[HD08]
Single table Developer must Yes, can be done. Yes, can be done. db4o stores objects as
to multiple write code to (embedded objects) objects, not in tables.
objects achieve this.
Assistance, ease of use
GUI to setup There is no Yes, Hibernate Tools Yes, Eclipse Dali There is no Mapping,
the mapping mapping - implemented as an project provides a but has Db4oEclipse,
83
integrated suite of powerful an Eclipse plugin to

Eclipse plugins. development explore and query the
environment for db4o database
Java Persistence. content.
Generation No Has reverse Has reverse -Not Applicable-
of the classes engineering tool, engineering tool.
hbm2hbmxml,
hbm2java.
Generation No Has schema Has support for -Not Applicable-
of the generation tool schema generation, has automatic schema
database hbm2ddl and existing schema. recognition.
schema org.jpox.autoCreate
(doesn't require its own Schema
data model)
(doesn't require its own
data model)
Lazy loading No Yes, has lazy Yes, is a JDO db4o provides a
loading. implementation. mechanism to give
the user fine grained
control over how
much he wants to pull
out of the database
when asking for an
object. This
mechanism is called
activation depth.
Caching Caching is Hibernate uses two Two levels of Db4o uses object
maintained by hand different caches for caching are available reference cache for
coding. Can use objects: first-level with JPOX. Has easy access to
CachedRowSet. cache and second- pluggable persistent objects
[GCS01] level cache. Query framework for during one
result sets may also external caching. transaction.
be cached by The
Query cache.
Optimized Yes, set the query Yes, has two Yes, allows control Yes, has enhancement
queries fetch size. when different and over fetching tools for Native query
you do complementary process. JDO2 optimization.
an update it's tuning strategies, provides a fetch size
straightforward global and per use on the Fetch Plan to
(although tedious) case. allow this control.
to write the code so
84
that only modified

columns are
updated.
Handle Developer must A session-level cache Yes, is a JDO Yes, provides internal
circular handle manually. resolves circular implementation and object id's to avoid
references references. by default uses level circular reference.
1 cache.
Handle Developer must Yes, by using Yes, by using Yes, by setting
cascade handle manually. cascades associations cascade. cascadeOnUpdate()
updates may be configured and
for cascading save, cascadeOnDelete()
delete, and/or
reattachment.
Bulk updates No, not without HQL now supports JDOQL has bulk db4o doesn't have any
or deletions using SQL. bulk UPDATE and delete but not bulk bulk
bulk DELETE update. insert/update/delete
queries. But do not mechanisms.
cause
cascade-deletes.
Evolution, compatibility:
Maintainabili hard to maintain. Easy to maintain. Easy to maintain. Yes, easy to maintain.
ty JDBC is tightly Hibernate is not Applications using
tied with the tightly tied with any objects with
underlaying underlaying database collection members
database. In (one-to-many
database if a relationships) will
column type benefit.
changes, or
application ported
to a different
database, this code
must be rewritten.
Possibility to You have to change Yes possible, Yes possible, Moving to a new tool
move to a all the code. depends on the depends on the (in this case OO
new mapping situation. If the metadata model. language) is not so
tool metadata models easy. ODBMS creates
aren't too different it a tight coupling
can be trivial. between your code
Should be pretty and your data storage.
straightforward to
convert, but then you
will have to get
85
familiar with the

metadata model of
other tool.
Serialization Yes supports Yes has support. Yes has support. Yes has support.
serialization.
Distributed Using JDBC for Distributed distributed (XA) From the API side,
objects transaction transactions are well transactions are there's no real
management in an supported. supported. can be difference between
environment utilized within a transactions
involving multiple J2EE environment executing
databases or using Java concurrently within
distributed Connector the same VM and
databases is not Architecture, JCA. transactions executed
trivial. against a remote
server. (db4o is
currently mostly
optimized for
embedded, local use
rather than Client-
Server. C/S isn't as
fast as ORM's)
Additional features
Freedom in Yes Yes, provides Yes, the only JDO Yes
the design of transparent constraint on any
the classes persistence for Java class that needs
POJOs, except the persisting is that it
no-argument has a default
constructor is a constructor.
requirement. Tools
like Hibernate use
reflection on this
constructor to
instantiate objects.
Less Yes Yes, hibernate does JPOX is very Does not require
constrains as not enforce on DB unobtrusive as far as schema files since it
possible on schema. the datastore schema runs natively. Since it
the database is concerned. saves the graph, no
schema linking entries need
to be made.
State This check has to supports the Can use Yes, has support.
information be added by the following object getObjectState.
on data developer. states: Transient,
86
Persistent, Detached
External No Yes, uses external Yes uses ORM No mapping file
mapping file mapping file. You MetaData file. JPOX required.
can also use supports both JPA1
annotations in and JDO2
addition to or as a annotations.
replacement of XML
mapping metadata.
Support for A DataSet can Yes, This pattern is Yes, has ability to Yes
disconnected be manipulated and known as session- attach/detach objects
mode operated upon both per-conversation. to/from the
in a connected and persistence graph.
disconnected
mode.
Interceptors Can be handled in Hibernate uses log4j can be configured to Can use log4j.
and a number of ways, , java.util.logging , log tracking the
delegation ex. log4jdbc is a or potentially any persistence process.
mechanisms Java JDBC driver another logging ex. Using Log4J,
that can log SQL framework. JDK1.4+
and/or JDBC calls
Support for supports calling Hibernate 3 Yes allows. Uses methods.
stored stored procedures introduced support overridden JDO by Complex select
procedures with the for queries via stored org.jpox.query.allow procedures might
CallableStatement procedures and AllSQLStaments require a separate
class functions. function.
constraints Developer must Hibernate Validator JPOX provides an Supports constraints.

handling code the handling. comes with some extension to JDO A constraint is
built-in constraints, that can give checked at commit-
which covers most significant benefit to time and a constraint
basic data checks. constraint handling. violation will cause
org.jpox.rdbms.cons an exception.
traintCreateMode
ex.<unique name=.>
Filtering Can be can use createFilter Can use setFilter. Yes
objects in programmed
memory through
FilteredRowSet.
Table 6: Comparison of ORM specific criteria
87
5.3. Comparison of performance:
In this section the performance of candidate tools is compared. This comparison is done by running
tests and recording the execution times. The tests were conducted on the original computer the
applications were developed on: a TOSHIBA T5500 Intel Core 2, 1.66 G Hz with 2 GB RAM, running
32 bit Windows XP Professional.
5.3.1. Use case specific comparison:
In this section I compared the execution times of the Use case modules. A table is shown with
execution times for each use case with each ORM candidate tool. Just below each table, its graph is
shown, the low the bar on the graph the fastest the tool.
88
'Administrator' Use case comparison:

using
t [time in ms] JDBC Hibernate JPOX JDO ODBMS (db4o)
1. admin login 312 1328 1390 406
2. add customer 313 1407 1468 78
3. find customer 15 47 375 78
4. update customer 31 46 297 94
5. delete customer 47 62 672 328
6. create new card 93 79 313 109
7. update PIN 15 31 1500 94
8. check all pending 16 94 1484 63
deposits
9. check pending 360 32 344 78
deposit for a customer
10. approve deposit 32 47 719 500
Table 7: administrator use case performance comparison
1600.000
1400.000
1200.000
1000.000
JDBC
800.000
Execution time
Hibernate
JPOX JDO
Db4o
600.000
400.000
200.000
0.000
1 2 3 4 5 6 7 8 9 10
Use case number
Illustration 14: administrator use case – performance comparison chart
89
'User' use case comparison:
using
1. User login 359 1375 250 468
2. check balance 16 15 16 16
3. withdraw cash 16 47 125 31
4. deposit money 15 1625 1703 31
5. mini statement 16 25 15 16
6. change PIN 15 32 31 31
Table 8: User use case - performance comparison
1800
1600
1400
1200
1000
JDBC
Executi on time
Hibernate
JPOX JDO
800 Db4o
600
400
200
0
1 2 3 4 5 6
Us e c ase number
Illustration 15: User use case - performance comparison chart
90
5.3.2. CRUD comparison:
In this section I compared the execution times of CRUD operations. A table is shown with execution
time for each set of objects. Just below each table, its graph is shown, the low the bar on the graph the
fastest the tool.
write, query, update and delete simple flat objects individually.
Create:
Writes objects to DB.
using
500 objects 3579 1359 3344 500
1000 objects 7110 2625 6703 937
5000 objects 74625 11922 39625 1312
10000 objects 134953 32234 107547 1750
Table 9: Create objects performance comparison
160000
140000
120000
100000
J D BC
80000
Execution time
H ibe rna te
J POX J D O
D b 4o
60000
40000
20000
0
500 objects 1000 objects 5000 objects 10000 objects
Illustration 16: Write - comparison chart
91
Read:
Retrieves objects by querying.
using
500 objects 5469 7312 3906 344
1000 objects 10125 11437 7156 703
5000 objects 272562 73438 43563 1453
10000 objects Very large 194531 118610 2578
Table 10: Read objects performance comparison
Read - comparison
400000
350000
300000
250000
JDBC
Execution time
Hibernate
200000 JPOX JDO
Db4o
150000
100000
50000
0
Illustration 17: Read comparison chart
92
Update:
reads and then updates an object.
using
500 objects 5047 6266 6406 359
1000 objects 21141 11125 12031 1110
5000 objects 205969 91985 81750 2422
Table 11: Update objects performance comparison
350000
300000
250000
200000
JDBC
Execution time
Hibernate
JPOX JDO
Db4o
150000
100000
50000
0
Illustration 18: Update comparison chart
93
Delete:
reads and then deletes an object.
using
500 objects 5500 7704 6657 625
1000 objects 16203 13328 12500 969
5000 objects 64734 109657 77297 1750
Table 12: Delete objects - performance comparison
350000
300000
250000
200000
JDBC
Execution time
Hibernate
JPOX JDO
Db4o
150000
100000
50000
0
Illustration 19: Delete - performance comparison chart
94
5.4. Recommendations and conclusion:
As you see above in sections 5.1, 5.2 and 5.3, there are numerous criteria, the importance of individual
criteria will depend on the respective application. Clearly, there is no best product for all situations.
However I drew some general conclusions from the results that answers the research questions formed
in chapter 1. These questions formed in chapter 1 served as guideline for the research done in the thesis.
The answers to these questions will now be given briefly recapitulating the main issues addressed in the
thesis.
The first question for which an answer was needed is:
Is ORM framework a replacement for JDBC?

The answer to this question: No. ORM frameworks use JDBC. It's ORM framework on top of JDBC,
not ORM framework instead of JDBC.
JDBC is theoretically faster (or the same) than any ORM tool since ORM tool is always reduced to
low-level JDBC calls. Even with hibernate, some advanced queries will require either direct JDBC or
good stored procedures; object mapping tools really don't eliminate complex database issues.
Use of ORM framework is an overhead for the applications which are :

• simple and use one database that never change
• need to put data to database tables, no further SQL queries
• there are no objects which are mapped to two different tables
ORM framework increases extra layers and complexity. So for these types of applications JDBC is the
best choice.
The use of O-R mapping technology like Hibernate or JDO O-R mappers has a strong negative impact
on performance. If you can't compensate by throwing hardware at your application, you may have to
avoid O-R mappers, if performance is important to you. Protagonists of O-R mapping technology may
tell you that caching will bring you back performance. Although this may be true, do not forget: Data
95
that comes from a cache can always be stale in a multi-user application. If you want your data to be up-
to-date, you have to reread from the database and an old cache that you can not use will even degrade
performance.
Now if we see disadvantages of JDBC, with JDBC, developer has to write code to map an object
model's data representation to a relational data model and its corresponding database schema.
Developer has to find out the efficient way to access database, i.e to select effective query from a
number of queries to perform same task. Application using JDBC to handle persistent data (database
tables) have database specific code in large amount. With JDBC, it is developer’s responsibility to
handle JDBC result set and convert it to Java objects through code to use this persistent data in
application. SQL looks like a foreigner in Java code, very ugly, difficult to write and refactor.
I think the main question a project team needs to settle on is whether or not to use an Object-Relational
Mapping (ORM) framework. If you decide to go with an ORM (which is what I'd usually recommend
for larger projects), you are indeed buying into some added complexity and learning curve, but in
exchange you'll get a great deal of power and flexibility. O-R mappers and object databases make life
so much easier and productive. Now, this arises the second question in this paper
How to select an Object-relational mapping tool which is suitable for the Java project in Hand?
This is not an easy question to answer in few words, a project team must check the criteria formed in
chapter 3, the analysis present in this chapter (Ch.5) and decide which criteria are critical for them. The
tools which I chose for this thesis, Hibernate and JPOX JDO passes almost all of the criteria. There
may be some issues in each tool, but there are workarounds for almost all of them. For these two tools
the community is so strong that the known issues are solved instantly and new versions with updated
features are released in regular periods. If you take a look at the source code of example implemented,
the task of storing objects is very similar among both the products.
Hibernate is often termed synonymous to ORM in Java world, but I would say there are many other
tools in market which are really good, I did not use any but as I was researching for ORM's I came
across Cayenne, TopLink and iBatis, which I would say probably be a good choice too. If you want to
96
go for JDO implementation, then I would say JPOX is the best open source JDO available at the
moment.
Finally, if there is problem using RDBMS with OO language, why not replace the whole system. This
leads to our last question in this paper
Can relational databases be replaced with Object-oriented databases?

The answer to this question: No. Object databases have not swept the marketplace. There are usually
good reasons for that. I don't think objects are always the most natural way to represent data. The
relational model has a lot going for it that the object model does not:
● A mathematical basis (set theory),
● A ubiquitous, standard language (SQL)
● A huge installed base
● Familiar to a large user and client community
● Large institutions have critical data tied up in them (e.g., banks)
● No compelling reason to switch
As would be expected, object databases like db4o provide best performance for deep inheritance
hierarchies and tree structures. Not especially. My point was more that, for some data operations, the
relational model is more suitable than an object one. Simple as that. The whole "ORM is inherently
better " thing is a fallacy. Right tool for the job, always.
Object databases have compelling reasons for existence, but not so strong a case that they could
displace the RDBMS from the "enterprise data" throne. the RDBMS has been, and will, in the absence
of a nearly catastrophic change to the contrary, continue to be, the choice of businesses all over the
world for storing data in a format that's easily-accessed from a variety of different systems.
97
Recommendations for further Research:
This research project has attempted to answer some questions regarding Object relational mapping and
its comparison. This relatively new area does still leave much to explore. There are a number of ideas
to extend on this research project, as well as new questions that could be answered.
The criteria defined in chapter 3 can be more researched and fine tuned by awarding points for each
criteria, I mean more statistical approach can be implemented for evaluation by introducing scoring.
In order to perform comparison analysis, a case study was conducted on an example banking
application. Of course one case study does not lead to a definitive answer. The comparison criteria
proposed here could certainly be tested more thoroughly on different applications, and improved using
the results of these tests. Also, few other ORM tools and databases (RDBMS & ODBMS) can be used
for further research.
98
Bibliography
Bibliography
[ADTSA06] Scott W Ambler - “Agile database techniques”, Wiley Publishing, Inc.

2006
[CHTRI08] “Complete Hibernate 3.0 Tutorial”, Retrieved on April 7, 2008.

http://www.roseindia.net/hibernate/index.shtml
[CRPIA05] Chris Richardson - “POJOs in action”, Manning Publications Co.

Greenwich, 2006.
[DB4O08] Db40 Documentation, Retrieved on May 5, 2008. http://www.db4o.com/
[DBT08] Db4o-7.2 Tutorial bundled with db4o-7.2 for Java, May 5, 2008.
[DMJLBH06] Dave Minter and Jeff Linwood - “Beginning Hibernate from novice to
Professional”, Apress. Berkley, August, 2006.
[EMMSF05] Amnon H. Eden , Tom Mens - “Measuring Software Flexibility”, 2006,

Retrieved on March 11 2008.
http://www.eden-study.org/articles/2006/measuring-sw-flexibility_ieesw.pdf
[GCS01] Jonathan Lurie , - “Develop a generic caching service to improve

performance, Build a timed cache with a background thread”, 20 July,
2001, Retrieved on June 05, 2008.
http://www.javaworld.com/javaworld/jw-07-2001/jw-0720-cache.html
[GEOUS08] Michael Gomoll - “The Ease-Of-Use Issue in Software Selection”,

Retrieved on May 06, 2008.
http://www.drj.com/drworld/content/w2_059.htm
[HD08] Hibernate documentation, 2008. Retrieved on April 02, 2008.

http://www.hibernate.org/hib_docs/reference/en/html/
[JDAA08] JDBC Data access API – Drivers, 2008. Retrieved on June 02, 2008.
http://developers.sun.com/product/jdbc/drivers
[JJO08] Java+JDBC+Oracle, Retrieved on May 06, 2008.

http://www.cse.unsw.edu.au/~jas/talks/jdbc/notes.html, 2008
[JPDB04] Jim Paterson - “Simple Object Persistence with the db4o Object
Database”, 2004. Retrieved on May 21, 2008.
http://www.onjava.com/pub/a/onjava/2004/12/01/db4o.html#resources
99
Bibliography
[JPHBK08] Christian Bauer, Gavin King - “Java Persistence with Hibernate”,

Manning Publications Co. USA, 2008
[JPN08] Eddy Young - “JPOX and Netbeans”, Retrieved on April 21, 2008.
http://www.jpox.org/docs/1_1/tutorials/netbeans.html
[JPOXD08] JPOX documentation, 2008. Retrieved on April 21, 2008.

http://www.jpox.org/
[JPT08] “JPOX – Tutorial”, 2008. Retrieved on April 21, 2008.

http://www.jpox.org/docs/1_1/tutorials/tutorial.html
[KBOSE05] Karin van den Berg - “Finding Open options An Open Source software
evaluation model with a case study on Course Management Systems”,
Tilburg, August 2005. Retrieved on March 11, 2008.
http://www.karinvandenberg.nl/Thesis.pdf
[KGPDM03] Kyle Gabhart - “Persistent Data Management”, April 02, 2003.

Retrieved on January 11, 2008.
http://www.ibm.com/developerworks/java/library/j-pj2ee3.html
[KSTGASCM86] Joseph k. Kearney, Robert L. Sedlmeyer, William B.Thompson, Michael

A Gray, and Michael A. Adler - “Software Complexity Measurement”,
1986. Retrieved on June 11, 2008.
[LGDN08] Brian Leonard, Troy Giunipero - “Working with the Java DB (Derby)
Database in NetBeans IDE”, 2008. Retrieved on December 03, 2008.
http://www.netbeans.org/kb/55/derby-demo.html#starting
[MGATM01] http://www.math.gordon.edu/courses/cs211/ATMExample/, 2001.

Retrieved on January 14, 2008.
[ORMA08] “Object Relational Mapping Articles”, 2007.

Retrieved on December 17, 2007.
[ORTC08] “Object relational tool comparison”, 2008. Retrieved on March 24, 2008.
http://c2.com/cgi-bin/wiki?ObjectRelationalToolComparison
[QMGSJ05] Qusay H Mahmoud - “Getting started with JDO”, 2005.

Retrieved on April 07, 2008.
http://java.sun.com/developer/technicalArticles/J2SE/jdo/
[SCUJWD06] Susan Cline - “Using JPOX JDO with Derby”, 2006.

Retrieved on April 08, 2008.
http://db.apache.org/derby/integrate/JPOX_Derby.html
100
Bibliography
[SSVUH05] Saritha.S.V - “Understanding Hibernate ORM for Java/J2EE”, 2005.

Retrieved on March 21, 2008.
http://www.codetoad.com/java_Hibernate.asp
[WSHWMT01] William D. Shoaff - “How to write a master's thesis in computer science”,

August 21, 2001. Retrieved on December 03, 2007.
http://cs.fit.edu/~wds/guides/howto/
[XCHSI04] Xavier Coulon, Christian Brousseau – “Hibernate simplifies inheritance

mapping”, Decebmer 14, 2004. Retrieved on March 03, 2007.
http://www.ibm.com/developerworks/library/j-hibernate/?ca=dnt-550
101
Appendix A
Appendix A
Example: ATM Banking application
I. Functional requirements:
This list of functional requirements was used in the example application. This list is constructed
using the main features from a website that gives detailed Requirements for Example ATM System:
[MGATM01]
The requirements from the above site included for User module of application and
Administrator module are created based on these.
i. User should have a savings account with the bank.

ii. User should have ATM facility with valid card with unique card number and a valid PIN
number.
iii. User should be acquainted with the basic transactions available in the ATM facility.
iv. Bank should provide a customer database with the details like account holder’s name, account
number, card number, PIN number, balance, etc.
v. Bank Administrator should have the control over the updating of the account details like:
○ Customer details
○ Updating the account balance

vi. Bank Administrator should have a facility to open/close a savings account with ATM facility for
a customer.
USER module:
i. The login window of the ATM should have fields for the entry of the valid ATM card number.
ii. If the card number is validated as valid card number, the application should prompt for the valid
PIN number or else it should display a message like:” Invalid card number. Please enter a valid
card number”, “Your account has been blocked”, etc. and should return back to the enter card
number screen.
iii. If PIN number is valid, user should be taken to the screen with the following options
○ Fast cash
○ Withdraw cash
○ Balance inquiry
○ Mini statement
○ PIN change
○ Deposit cash
102
Appendix A
○ Money transfer
○ Utility bill payment
iv. Fast cash: On selection of this option, user is prompted to select from the list of predefined
withdraw amounts like 1000, 2000, 5000, etc. Only the options with amount below the account
balance should be active.
v. Withdraw cash: On selection of this option, user is prompted to enter the amount to be
withdrawn and click the “yes” button. If the amount is within his balance then the transaction
takes place. If the amount is not within the balance, then a message “insufficient balance” is
displayed. There should be a “clear” button in case the user mistypes the amount.
vi. Balance inquiry: On selection of this option, user is prompted whether he/she wants a printed
slip or just the display on screen.
vii. Mini statement: On selection of this option, user’s ten latest transactions will be printed.
viii.PIN change: On selection of this option, a screen with new PIN and reenter new PIN fields will
be displayed. The user fills the fields and clicks on the “change” button. If the new PIN field
entry and the reenter new PIN field entry matches then the PIN will be replaced with the new
PIN number.
ix. Deposit cash: On selection of this option, user is requested to enter the amount he has deposited
in the ATM. Upon confirmation from the user, the transaction will kept in pending for bank
administrator approval.
ADMIN module:
i. Login window of the ADMIN module should have fields for username and password.
ii. Upon authentication of the username and password, then a screen with the following options
appear:
○ ADD customer
○ UPDATE customer info
○ FIND customer
○ PENDING deposits
iii. ADD customer: This option will present a screen to the administrator with the fields to fill the
customer details. After all the fields have been filled, administrator will click the “create”
button, then automatically account number, card number and the PIN number are generated.
103
Appendix A
iv. UPDATE customer info: This option will present a screen to the administrator where he can
fill either the account number or the card number and upon click the “get info” button user info
will be displayed and a provision for updating the info will be provided.
v. FIND customer: This option will present a screen to the administrator where he can fill either
the account number or the card number and upon click the “view” button user info will be
displayed.
vi. PENDING deposits: This option will present a screen to the administrator where all the
pending deposits will be displayed. Upon selection of a particular deposit another screen with
the “DEPOSIT” button will appear. If the DEPOSIT button is clicked, then the amount will be
deposited into the account.
II. Use Cases for Example ATM Banking application:
The following use cases are drawn by the requirements mentioned above. These use cases are
applied for the example persistence layer development.
104
Appendix A
User use case: The following is the use case for User module.
Illustration 20: User use case

diagram
105
Appendix A
Administrator use case: The following is the use case for Administrator module.
Illustration 21: Administrator use case diagram
106
Appendix A
III. Domain class diagram: The following is the Class diagram for domain classes of ATM
banking application.
Illustration 22: ATM banking application Domain class diagram
107
Appendix A
IV. EER diagram: The following is Enhanced Entity-Relationship diagram for ATM banking
application.
Illustration 23: ATM banking application EER diagram
108

A Comparative Analysis of Object-Relational Mappings For Java

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

A Comparative Analysis of Object-Relational Mappings For Java

Uploaded by

Copyright:

Available Formats

INSTITUTE OF COMPUTING SCIENCE

POZNAN UNIVERSITY OF TECHNOLOGY

University of Applied Sciences at Braunschweig/Wolfenbuettel

“A Comparative Analysis of Object-relational mappings for Java”

Braunschweig, June 2008

Submitted in partial fulfillment of the requirements for the degree

University of Applied Sciences Braunschweig/Wolfenbuettel, Germany

While object-oriented programming and high-performance databases are now mainstream,

Braunschweig, Germany, July 2008.

Today's Internet-driven view of information systems is helping to popularize Java as an application

1.1. Objective and Research Question:

The research question addressed in this thesis is the following:

To answer this question, the following subquestions are used:

● What is mismatch problem

1.2.3. Case study:

1.2.4. Comparative study:

Illustration 1: Thesis outline

Chapter 2 is an introduction to Object-relational mapping, including the Object-relational mapping

Chapter 2. About Object-Relational mapping

2.1. Introduction to object:

2.1.1. Object-oriented programming (OOP):

Object-oriented programming (OOP) is a programming language model organized around "objects"

2.1.2. Objects in object oriented programming:

As stated above in object-oriented programming, an object is an instance (or instantiation) of a class.

2.1.3. Basics of Object-oriented programming:

A particular object, an instance of a class.

2.2. Introduction to Java:

2.3. Introduction to Databases:

2.3.1. Database management system (DBMS):

2.3.2. Relational Database management system (RDBMS):

2.3.3. Object-oriented database management system (OODBMS):

An object-oriented database management system (OODBMS), sometimes shortened to ODBMS for

2.4. Introduction to persistence:

2.4.1. Persistence in Object-oriented applications:

2.4.2. Persistence in Java:

2.5. The O/R impedance mismatch:

The following are the common mismatches between both paradigms:

● The problem of granularity

● The problem of subtypes (inheritance, polymorphism)

● The problem of identity

● Problems relating to associations

● The problem of data navigation

2.6. Introduction to Object-relational mapping:

Object-relational mapping is a programming

2.7. Object-relational mapping (ORM) tools:

• Cayenne, apache, open source for java

• Ebean, open source ORM Framework

• Enterprise Objects Framework, Mac OS X/Java, part of Apple WebObjects

• Hibernate, open source ORM Framework, widely used

• iBATIS, maintained by ASF, and with .NET port.

• Java Data Objects (JDO)

• JPOX, open source JDO 2 reference implementation

• Kodo, commercial implementation of both the JDO and JPA API.

• OpenJPA, apache, open source, supports JPA API.

2.8. Definitions, acronyms and abbreviations:

ORM Object Relational Mapping

Chapter 3. Comparative analysis criteria

3.1. The ORM comparative analysis criteria:

II. Object Relational Tool Comparison

III. “How-To-Select an Object-Relational Mapping Tool for .NET” by By Jason Mauss

General Criteria ORM specific Criteria

Table 2: Comparison criteria

3.2. Criteria description: