toring and retrieving information for most applications usually involves some form of interaction with a relational database. This has presented a fundamental problem for developers for quite some time since the design of relational data and object-oriented instances share very different relationship structures within their respective environments. Relational databases are structured in a tabular configuration and object-oriented instances are typically structured in a hierarchical manner. This “impedance mismatch” has led to the development of several different object-persistence technologies attempting to bridge the gap between the relational world and the object-oriented world. The Hibernate persistence framework provides yet another means for bridging this gap.

This article is the second in a series discussing how three different object-persistence technologies (EJB, Java Data Objects, and Hibernate) attempt to simplify the chore of connecting relational databases and the Java programming language.

Introducing Object Persistence
The task of persisting Java objects to a relational database is currently being facilitated by a number of different tools which allow developers to direct persistence engines in converting Java objects to database columns/records and back. This task involves serializing hierarchically-structured Java objects to a tabular-structured database and vice versa. Essential to this effort is the need to map Java objects to database columns and records in a manner optimized for speed and efficiency.

The Hibernate framework tackles the Java-object-to-database problem as elegantly as any framework currently available. Hibernate works by persisting and restoring plain old Java Objects (POJOs) using a very transparent and low-profile programming model.

An Overview of Hibernate
Hibernate is a Java framework that provides object/relational mapping mechanisms to define how Java objects are stored, updated, deleted, and retrieved. In addition, Hibernate offers query and retrieval services that can optimize development efforts within SQL and JDBC environments. Ultimately, Hibernate reduces the effort needed to convert between relational database result-sets and graphs of Java objects.

One of its unique features is that Hibernate does not require developers to implement proprietary interfaces or extend proprietary base classes in order for classes to be made persistent. Instead, Hibernate relies on Java reflection and runtime augmentation of classes using a powerful, high-performance, code-generation library for Java called CGLIB. CGLIB is used to extend Java classes and implement Java interfaces at runtime.

The Hibernate Configuration File
You can configure the Hibernate environment in a couple of ways. One standard way that proves very flexible and convenient is to store the configuration in a file named hibernate.cfg.xml. You place the configuration file at the root of a Web application’s context classpath (e.g. WEB-INF/classes). You then access the file and read it using the net.sf.hibernate.cfg.Configuration class at runtime.

The hibernate.cfg.xml file defines information about the database connection, the transaction factory class, resource mappings, etc. The following code demonstrates a typical configuration file:

            org.hsqldb.jdbcDriver      jdbc:hsqldb:data/userejb      sa            true      net.sf.hibernate.dialect.HSQLDialect               net.sf.hibernate.transaction.JDBCTransactionFactory                     

The Hibernate Mapping Configuration File
Hibernate applications make use of mapping files containing metadata defining object/relational mappings for Java classes. A mapping file is designated with a suffix of .hbm.xml. Within each configuration file, classes to be made persistent are mapped to database tables and properties are defined which map class-fields to columns and primary keys. The following code illustrates a typical Hibernate configuration file named UserInfo.hbm.xml:

Hibernate Sessions
In order to make use of Hibernate’s persistence mechanisms, you must initialize the Hibernate environment and obtain a Session object from Hibernate’s SessionFactory class. The following snippet of code illustrates these processes:

// Initialize the Hibernate environmentConfiguration cfg = new Configuration().configure();// Create the session factorySessionFactory factory = cfg.buildSessionFactory();// Obtain the new session objectSession session = factory.openSession();

The call to Configuration().configure() loads the hibernate.cfg.xml configuration file and initializes the Hibernate environment. Once the configuration is initialized, you can make any additional modifications you desire programmatically. However, you must make these modifications prior to creating the SessionFactory instance.

An instance of SessionFactory is typically created once and used to create all sessions related to a given context.

A Hibernate Session object represents a single unit-of-work for a given data store and is opened by a SessionFactory instance. You must close Sessions when all work for a transaction is completed. The following illustrates a typical Hibernate session:

Session session = null;UserInfo user = null;Transaction tx = null;try{   session = factory.openSession();   tx = session.beginTransaction();   user = (UserInfo)session.load(UserInfo.class, id);   tx.commit();}catch(Exception e){   if (tx != null)   {      try      {         tx.rollback();      }      catch (HibernateException e1)      {         throw new DAOException(e1.toString());      }   }   throw new DAOException(e.toString());}finally{   if (session != null)   {      try      {         session.close();      }      catch (HibernateException e)      {      }   }}

The Hibernate Query Language
Hibernate offers a query language that embodies a very powerful and flexible mechanism to query, store, update, and retrieve objects from a database. This language, the Hibernate Query Language (HQL), is an object-oriented extension to SQL. HQL allows access to data in a variety of ways including object-oriented queries, as in the find() method of the Session object illustrated by the following example:

List users =   session.find("from UserInfo as u where u.fullName = ?",                "John Doe",                Hibernate.STRING);

You can construct dynamic queries using Hibernate’s criteria query API:

Criteria criteria = session.createCriteria(UserInfo.class);criteria.add(Expression.eq("fullName", "John Doe"));criteria.setMaxResults(20);List users = criteria.list();

If you prefer to use native SQL, you may express a query in SQL, using createSQLQuery():

List users =   session.createSQLQuery("SELECT {user.*} FROM USERS AS {user}",                           "user",                          UserInfo.class).list();

Large numbers of objects returned from a query will be loaded as needed when one of the iterate() methods is used. The iterate() methods typically offer better performance since they load objects on demand:

Iterator iter =   session.iterate("from UserInfo as u where u.city = New York"); while (iter.hasNext()){   UserInfo user = (UserInfo)iter.next();   // process the user object here}

The Application and Runtime Environment
This article will use JBoss 3.2.3 as the deployment and runtime environment for the examples that follow. You’ll design a simple Web application that allows user accounts to be created and retrieved using a Web browser. Client requests will be passed from a browser to a Java servlet, which communicates with a user service, which communicates with Hibernate-based data access objects (DAOs), as shown in Figure 1.

Figure 1. Client Requests: This image shows the steps through which a a client request is processed.

The DAO pattern abstracts and encapsulates all access to the data source. The application has one DAO interface, UserDao. The implementation class, HibernateUserDao contains Hibernate-specific logic to handle data-management duties for a given user.

You must construct or modify some of the configuration files to accommodate the needs of Hibernate. First, modify the jaws.xml file to define the datasource for the application:

jaws.xml   java:/DefaultDS   Hypersonic SQL

Next, modify the hibernate.cfg.xml file to define the Hibernate properties that will be loaded by the application when Hibernate is configured. Among other things, the environment is configured to use HSQL as the database and a mapping resource is defined for the UserInfo class:

hibernate.cfg.xml            org.hsqldb.jdbcDriver      jdbc:hsqldb:data/userejb      sa            true      net.sf.hibernate.dialect.HSQLDialect               net.sf.hibernate.transaction.JDBCTransactionFactory                     net.sf.hibernate.cache.HashtableCacheProvider            update               

The Web Tier Configuration
Each client HTTP request is handled by a FrontController-style servlet embodied within an instance of UserInfoServlet. The UserInfoServlet instance converts each request to a business-service request and then calls the appropriate business service for processing.

The UserInfoServlet is shown in Listing 1.

The Business Tier
Each client HTTP request is converted to a business-service request and passed to the appropriate business service for processing. Each business service object performs the necessary business logic and makes use of the appropriate DAO for data-store access.

The UserService class encapsulates methods for operating on UserInfo objects including storing, updating, deleting, and retrieving instances of UserInfo. The UserService class is shown in Listing 2.

The UserService class makes use of the UserInfo class, which represents a given user. The UserInfo class is shown in Listing 3.

The UserInfo class represents a given user and is configured for Hibernate in the file, UserInfo.hbm.xml.

The Data Tier
Each business-service request is passed to the appropriate business service for processing. A business service performs the necessary business logic and makes use of the appropriate DAO for data-store access. Each DAO performs the necessary interactions with Hibernate in order to act upon a given data store. The UserDAO interface defines the methods each DAO must implement.

The UserDAO Interface

package com.jeffhanson.datatier;import com.jeffhanson.businesstier.model.UserInfo;public interface UserDAO{   public UserInfo createUser(String id,                              String fullName,                              String address,                              String city,                              String state,                              String zip)      throws DAOException;   public UserInfo readUser(String id)      throws DAOException;   public UserInfo[] readUsersByState(String state)      throws DAOException;   public void updateUser(UserInfo userInfo)      throws DAOException;   public void deleteUser(UserInfo userInfo)      throws DAOException;}

An implementation of the UserDAO interface enables access to the UserInfo object’s data store, and is provided by the HibernateUserDAO class (see Listing 4).

Closing the Gap
The architectural differences between Java object hierarchies and relational database tables make the task of persisting Java object data to and from relational databases quite daunting for developers. The “impedance mismatch” between relational tables and Java object hierarchies has led to the development of several different object-persistence technologies attempting to close the gap between the relational world and the object-oriented world. The Hibernate framework defines an object/relational mapping mechanism and query language that makes storage and retrieval of Java objects to and from a data store a relatively simple proposition.