The diagram below provides a high-level view of the Hibernate architecture:
We do not have the scope in this document to provide a more detailed view of all the runtime architectures available; Hibernate is flexible and supports several different approaches. We will, however, show the two extremes: "minimal" architecture and "comprehensive" architecture.
This next diagram illustrates how Hibernate utilizes database and configuration data to provide persistence services, and persistent objects, to the application.
The "minimal" 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 "comprehensive" architecture abstracts the application away from the underlying JDBC/JTA APIs and allows Hibernate to manage the details.
Here are some definitions of the objects depicted in the diagrams:
- SessionFactory (
A threadsafe, immutable cache of compiled mappings for a single database. A factory for
Session and a client of
SessionFactory can hold an optional (second-level) cache of data that is reusable between transactions at a process, or cluster, level.
- Session (
A single-threaded, short-lived object representing a conversation between the application and the persistent store. It wraps a JDBC connection and is a factory for
Session holds a mandatory first-level cache of persistent objects that are used when navigating the object graph or looking up objects by identifier.
- Persistent objects and collections
Short-lived, single threaded objects containing persistent state and business function. These can be ordinary JavaBeans/POJOs. They are associated with exactly one
Session. Once the
Session is closed, they will be detached and free to use in any application layer (for example, directly as data transfer objects to and from presentation).
- Transient and detached 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
- Transaction (
(Optional) A single-threaded, short-lived object used by the application to specify atomic units of work. It abstracts the application from the underlying JDBC, JTA or CORBA transaction. A
Session might span several
Transactions in some cases. However, transaction demarcation, either using the underlying API or
Transaction, is never optional.
- ConnectionProvider (
(Optional) A factory for, and pool of, JDBC connections. It abstracts the application from underlying
DriverManager. It is not exposed to application, but it can be extended and/or implemented by the developer.
- TransactionFactory (
(Optional) A factory for
Transaction instances. It is not exposed to the application, but it can be extended and/or implemented by the developer.
- Extension Interfaces
Hibernate offers a range of optional extension interfaces you can implement to customize the behavior of your persistence layer. See the API documentation for details.
Given a "minimal" architecture, the application bypasses the
ConnectionProvider APIs to communicate with JTA or JDBC directly.