A SessionFactory is an expensive-to-create, threadsafe object intended to be shared by all application threads. A Session is an inexpensive, non-threadsafe object that should be used once, for a single business process, and then discarded. For example, when using Hibernate in a servlet-based application, servlets could obtain a SessionFactory using

SessionFactory sf = (SessionFactory)getServletContext().getAttribute("my.session.factory");

Each call to a service method could create a new Session, flush() it, commit() its connection, close() it and finally discard it. (The SessionFactory may also be kept in JNDI or in a static Singleton helper variable.)

In a stateless session bean, a similar approach could be used. The bean would obtain a SessionFactory in setSessionContext(). Then each business method would create a Session, flush() it and close() it. Of course, the application should not commit() the connection. (Leave that to JTA, the database connection participates automatically in container-managed transactions.)

We use the Hibernate Transaction API as discussed previously, a single commit() of a Hibernate Transaction flushes the state and commits any underlying database connection (with special handling of JTA transactions).

Ensure you understand the semantics of flush(). Flushing synchronizes the persistent store with in-memory changes but not vice-versa. Note that for all Hibernate JDBC connections/transactions, the transaction isolation level for that connection applies to all operations executed by Hibernate!

The next few sections will discuss alternative approaches that utilize versioning to ensure transaction atomicity. These are considered "advanced" approaches to be used with care.

You should observe the following practices when creating Hibernate Sessions:

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

Then for objects attached to 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).

Many business processes require a whole series of interactions with the user interleaved with database accesses. In web and enterprise applications it is not acceptable for a database transaction to span a user interaction.

Maintaining isolation of business processes becomes the partial responsibility of the application tier, hence we call this process a long running application transaction. A single application transaction usually spans several database transactions. It will be atomic if only one of these database transactions (the last one) stores the updated data, all others simply read data.

The only approach that is consistent with high concurrency and high scalability is optimistic concurrency control with versioning. Hibernate provides for three possible approaches to writing application code that uses optimistic concurrency.

// foo is an instance loaded earlier by the Session
session.reconnect();
foo.setProperty("bar");
session.flush();
session.connection().commit();
session.disconnect();

// foo is an instance loaded by a previous Session
foo.setProperty("bar");
session = factory.openSession();
session.saveOrUpdate(foo);
session.flush();
session.connection().commit();
session.close();

// foo is an instance loaded by a previous Session
session = factory.openSession();
int oldVersion = foo.getVersion();
session.load( foo, foo.getKey() );
if ( oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
foo.setProperty("bar");
session.flush();
session.connection().commit();
session.close();

The first approach described above is to maintain a single Session for a whole business process thats spans user think time. (For example, a servlet might keep a Session in the user's HttpSession.) For performance reasons you should

before waiting for user activity. The method Session.disconnect() will disconnect the session from the JDBC connection and return the connection to the pool (unless you provided the connection).

Session.reconnect() obtains a new connection (or you may supply one) and restarts the session. After reconnection, to force a version check on data you aren't updating, you may call Session.lock() on any objects that might have been updated by another transaction. You don't need to lock any data that you are updating.

Heres an example:

SessionFactory sessions;
List fooList;
Bar bar;
....
Session s = sessions.openSession();

Transaction tx = null;
try {
    tx = s.beginTransaction();

    fooList = s.find(
    	"select foo from eg.Foo foo where foo.Date = current date"
        // uses db2 date function
    );
    bar = (Bar) s.create(Bar.class);

    tx.commit();
}
catch (Exception e) {
    if (tx!=null) tx.rollback();
    s.close();
    throw e;
}
s.disconnect();

Later on:

s.reconnect();

try {
    tx = s.beginTransaction();

    bar.setFooTable( new HashMap() );
    Iterator iter = fooList.iterator();
    while ( iter.hasNext() ) {
        Foo foo = (Foo) iter.next();
        s.lock(foo, LockMode.READ);    //check that foo isn't stale
        bar.getFooTable().put( foo.getName(), foo );
    }

    tx.commit();
}
catch (Exception e) {
    if (tx!=null) tx.rollback();
    throw e;
}
finally {
    s.close();
}

You can see from this how the relationship between Transactions and Sessions is many-to-one, A Session represents a conversation between the application and the database. The Transaction breaks that conversation up into atomic units of work at the database level.

It is not intended that users spend much time worring about locking strategies. Its usually enough to specify an isolation level for the JDBC connections and then simply let the database do all the work. However, advanced users may sometimes wish to obtain exclusive pessimistic locks, or re-obtain locks at the start of a new transaction.

Hibernate will always use the locking mechanism of the database, never lock objects in memory!

The LockMode class defines the different lock levels that may be acquired by Hibernate. A lock is obtained by the following mechanisms:

The "explicit user request" is expressed in one of the following ways:

If Session.load() is called with UPGRADE or UPGRADE_NOWAIT, and the requested object was not yet loaded by the session, the object is loaded using SELECT ... FOR UPDATE. If load() is called for an object that is already loaded with a less restrictive lock than the one requested, Hibernate calls lock() for that object.

Session.lock() performs a version number check if the specified lock mode is READ, UPGRADE or UPGRADE_NOWAIT. (In the case of UPGRADE or UPGRADE_NOWAIT, SELECT ... FOR UPDATE is used.)

If the database does not support the requested lock mode, Hibernate will use an appropriate alternate mode (instead of throwing an exception). This ensures that applications will be portable.