Hibernate.orgCommunity Documentation
The diagram below provides a high-level view of the Hibernate architecture:
org.hibernate.SessionFactory
)org.hibernate.Session
)
Short-lived, single threaded objects containing persistent state and business
function. These can be ordinary JavaBeans/POJOs. They are associated with exactly one
org.hibernate.Session
. Once the
org.hibernate.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). Chapter 11, Working with objects discusses transient,
persistent and detached object states.
Instances of persistent classes that are not currently associated with a
org.hibernate.Session
. They may have been instantiated by
the application and not yet persisted, or they may have been instantiated by a
closed org.hibernate.Session
.
Chapter 11, Working with objects discusses transient, persistent and detached object states.
org.hibernate.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 org.hibernate.Session
might span several
org.hibernate.Transaction
s in some cases. However,
transaction demarcation, either using the underlying API or
org.hibernate.Transaction
, is never optional.
org.hibernate.connection.ConnectionProvider
)
(Optional) A factory for, and pool of, JDBC connections. It abstracts the application from
underlying javax.sql.DataSource
or
java.sql.DriverManager
. It is not exposed to application,
but it can be extended and/or implemented by the developer.
org.hibernate.TransactionFactory
)
(Optional) A factory for org.hibernate.Transaction
instances. It is not exposed to the application, but it can be extended and/or
implemented by the developer.
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.
Another feature available as a JMX service is runtime Hibernate statistics. See Section 3.4.6, “Hibernate statistics” for more information.
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 13, Transactions and Concurrency for more information and code examples.
The hibernate.current_session_context_class
configuration parameter
defines which org.hibernate.context.CurrentSessionContext
implementation
should be used. For backwards compatibility, if this configuration parameter is not set
but a org.hibernate.transaction.TransactionManagerLookup
is configured,
Hibernate will use the org.hibernate.context.JTASessionContext
.
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".
Copyright © 2004 Red Hat, Inc.