Hibernate.orgCommunity Documentation
Table of Contents
Hibernate, as an ORM solution, effectively "sits between" the Java application and the Relational Database, as can be seen in the diagram above. The Java application makes use of the Hibernate APIs to load, store, query, etc its domain data. Here we will introduce the essential Hibernate APIs. This will be a brief introduction; we will discuss these contracts in detail later.
org.hibernate.SessionFactory
)
A thread-safe (and immutable) representation of the mapping of the application
domain model to a database. Acts as a factory for
org.hibernate.Session
instances.
A SessionFactory is very expensive to create; there should be only one SessionFactory for an application for a given database. Maintains services that Hibernate uses across all Sessions such as second level caches, connection pools, transaction system integrations, etc.
org.hibernate.Session
)A single-threaded, short-lived object conceptually modeling a "Unit of Work"[PoEAA].
Wraps a JDBC java.sql.Connection
. Acts as a factory for
org.hibernate.Transaction
instances. Maintains a
generally "repeatable read" persistence context (first level cache) of the application's
domain model.
org.hibernate.Transaction
)A single-threaded, short-lived object used by the application to demarcate individual physical transaction boundaries. It acts as an abstraction API to isolate the application from the underling transaction system in use (JDBC, JTA, CORBA, etc).
Most applications using Hibernate need some form of "contextual" session, where a given
session is in effect throughout the scope of a given context. However, across applications
the definition of what constitutes a context is typically different; different contexts
define different scopes to the notion of current. Applications using Hibernate prior
to version 3.0 tended to utilize either home-grown ThreadLocal
-based
contextual sessions, helper classes such as HibernateUtil
, or utilized
third-party frameworks, such as Spring or Pico, which provided proxy/interception-based contextual sessions.
Starting with version 3.0.1, Hibernate added the SessionFactory.getCurrentSession()
method. Initially, this assumed usage of JTA
transactions, where the
JTA
transaction defined both the scope and context of a current session.
Given the maturity of the numerous stand-alone
JTA TransactionManager
implementations, most, if not all,
applications should be using JTA
transaction management, whether or not
they are deployed into a J2EE
container. Based on that, the
JTA
-based contextual sessions are all you need to use.
However, as of version 3.1, the processing behind
SessionFactory.getCurrentSession()
is now pluggable. To that
end, a new extension interface, org.hibernate.context.spi.CurrentSessionContext
,
and a new configuration parameter, hibernate.current_session_context_class
,
have been added to allow pluggability of the scope and context of defining current sessions.
See the Javadocs for the org.hibernate.context.spi.CurrentSessionContext
interface for a detailed discussion of its contract. It defines a single method,
currentSession()
, by which the implementation is responsible for
tracking the current contextual session. Out-of-the-box, Hibernate comes with three
implementations of this interface:
org.hibernate.context.internal.JTASessionContext
: current sessions
are tracked and scoped by a JTA
transaction. The processing
here is exactly the same as in the older JTA-only approach. See the Javadocs
for details.
org.hibernate.context.internal.ThreadLocalSessionContext
:current
sessions are tracked by thread of execution. See the Javadocs for details.
org.hibernate.context.internal.ManagedSessionContext
: current
sessions are tracked by thread of execution. However, you are responsible to
bind and unbind a Session
instance with static methods
on this class: it does not open, flush, or close a Session
.
Typically, the value of this parameter would just name the implementation class to use. For the three out-of-the-box implementations, however, there are three corresponding short names: "jta", "thread", and "managed".
The first two implementations provide a "one session - one database transaction" programming
model. This is also known and used as session-per-request. The beginning
and end of a Hibernate session is defined by the duration of a database transaction.
If you use programmatic transaction demarcation in plain JSE without JTA, you are advised to
use the Hibernate Transaction
API to hide the underlying transaction system
from your code. If you use JTA, you can utilize the JTA interfaces to demarcate transactions. If you
execute in an EJB container that supports CMT, transaction boundaries are defined declaratively
and you do not need any transaction or session demarcation operations in your code.
Refer to Chapter 7, Transactions and concurrency control for more information and code examples.
The hibernate.current_session_context_class
configuration parameter
defines which org.hibernate.context.spi.CurrentSessionContext
implementation
should be used. For backwards compatibility, if this configuration parameter is not set
but a org.hibernate.engine.transaction.jta.platform.spi.JtaPlatform
is configured,
Hibernate will use the org.hibernate.context.internal.JTASessionContext
.