Java Reference
In-Depth Information
The Session and Related Objects
The session is always created from a SessionFactory . The SessionFactory is a heavyweight
object, and there would normally be a single instance per application. In some ways, it is
a little like a connection pool in a connected application. In a J2EE application, it would typi-
cally be retrieved as a JNDI resource. It is created from a Configuration object, which in turn
acquires the Hibernate configuration information and uses this to generate an appropriate
SessionFactory instance.
The session itself has a certain amount in common with a JDBC Connection object. To
read an object from the database, you must use a session directly or indirectly. An example
of a direct use of the session to do this would be, as in Chapter 1, calling the session.get()
method, or creating a Query object from the session (a Query is very much like a
PreparedStatement ).
An indirect use of the session would be using an object itself associated with the session.
For example, if we have retrieved a Phone object from the database using a session directly, we
can retrieve a User object by calling Phone 's getUser() method, even if the associated User
object has not yet been loaded (as a result of lazy loading).
An object that has not been loaded via the session can be explicitly associated with the
session in several ways, the simplest of which is to call the session.update() method passing
in the object in question.
The session does a lot more than this, however, as it provides some caching functionality,
manages the lazy loading of objects, and watches for changes to associated objects (so that
the changes can be persisted to the database).
A Hibernate transaction is typically used in much the same way as a JDBC transaction.
It is used to batch together mutually dependent Hibernate operations, allowing them to be
completed or rolled back atomically, and to isolate operations from external changes to the
database. Hibernate can also take advantage of a transaction's scope to limit unnecessary
JDBC “chatter,” queuing SQL to be transmitted in a batch at the end of the transaction when
possible.
We will discuss all of this in much greater detail in Chapter 4, but for now it suffices that
we need to maintain a single SessionFactory for the entire application. However, a session
should only be accessed within a single thread of execution. Because a session also represents
information cached from the database, it is desirable to retain it for use within the thread until
anything (specifically any Hibernate exception) causes it to become invalid.
We present in Listing 3-15 a pattern from which Data Access Objects (DAOs) can be
derived, providing an efficient way for a thread to retrieve and (if necessary) create its sessions
with a minimal impact on the clarity of the code.
Listing 3-15. The Base Class Used to Manage the Session in the Example
package sample.dao;
import java.util.logging.Level;
import java.util.logging.Logger;
Search WWH ::




Custom Search