Chapter 2. Architecture

2.1. Overview

A (very) high-level view of the Hibernate architecture:

This diagram shows Hibernate using the database and configuration data to provide persistence services (and persistent objects) to the application.

We would like to show a more detailed view of the runtime architecture. Unfortunately, Hibernate is flexible and supports several approaches. We will show the two extremes. The "lite" architecture has the application provide its own JDBC connections and manage its own transactions. This approach uses a minimal subset of Hibernate's APIs:

The "full cream" architecture abstracts the application away from the underlying JDBC / JTA APIs and lets Hibernate take care of the details.

Heres some definitions of the objects in the diagrams:

SessionFactory (net.sf.hibernate.SessionFactory)

A threadsafe (immutable) cache of compiled mappings. A factory for Session. A client of ConnectionProvider.

Might hold a cache of data that is be reusable between transactions.

Session (net.sf.hibernate.Session)

A single-threaded, short-lived object representing a conversation between the application and the persistent store. Wraps a JDBC connection. Factory for Transaction.

Holds a cache of persistent objects.

Persistent Objects and Collections

Short-lived, single threaded objects containing persistent state and business function. These might be ordinary JavaBeans, the only special thing about them is that they are currently associated with (exactly one) Session.

Transient Objects and Collections

Instances of persistent classes that are not currently associated with a Session. They may have been instantiated by the application and not (yet) persisted or they may have been instantiated by a closed Session.

Transaction (net.sf.hibernate.Transaction)

(Optional) A single-threaded, short-lived object used by the application to specify atomic units of work. Abstracts application from underlying JDBC, JTA or CORBA transaction. A Session might span several Transactions.

ConnectionProvider (net.sf.hibernate.connection.ConnectionProvider)

(Optional) A factory for (and pool of) JDBC connections. Abstracts application from underlying Datasource or DriverManager. Not exposed to application.

TransactionFactory (net.sf.hibernate.TransactionFactory)

(Optional) A factory for Transaction instances. Not exposed to the application.

Given a "lite" architecture, the application bypasses the Transaction / TransactionFactory and / or ConnectionProvider APIs to talk to JTA or JDBC directly.

2.2. Persistent Object Identity

The application may concurrently access the same persistent state in two different sessions. However, an instance of a persistent class is never shared between two Session instances. Hence there are two different notions of identity:

Persistent Identity

foo.getId().equals( bar.getId() )

JVM Identity

foo==bar

Then for objects returned by a particular Session, the two notions are equivalent. However, while the application might concurrently access the "same" (persistent identity) business object in two different sessions, the two instances will actually be "different" (JVM identity).

This approach leaves Hibernate and the database to worry about concurrency (the application never needs to synchronize on any business object, as long as it sticks to a single thread per Session) or object identity (within a session the application may safely use == to compare objects).

2.3. JMX Integration

JMX is the J2EE standard for management of Java components. Hibernate may be managed via a JMX standard MBean but because most application servers do not yet support JMX, Hibernate also affords some non-standard configuration mechanisms.

Please see the Hibernate website for more information on how to configure Hibernate to run as a JMX component inside JBoss.

2.4. JCA Support

Hibernate may also be configured as a JCA connector. Please see the website for more details.