Hibernate を使ったアプリケーションは、ほとんど、なんらかの形で「コンテキスト上の」セッションが必要になります。「コンテキスト上のセッション」は、特定のコンテキストのスコープのなかで有効なセッションのことです。しかし、通常アプリケーションごとにコンテキストを構成するものの定義は異なります。しかも、異なる複数のコンテキストは、現時点に対して異なるスコープを定義します。バージョン3.0より前の Hibernate では、自作の ThreadLocal ベースの「コンテキスト上のセッション」を利用するか、 HibernateUtil のようなヘルパークラスを利用するか、 proxy/interception ベースの「コンテキスト上のセッション」を提供する （Spring や Pico のような）サードパーティのフレームワークを利用するかのいずれかでした。

バージョン 3.0.1 から、 Hibernate には SessionFactory.getCurrentSession() メソッドが加わりました。これは、 JTA トランザクションの使用を前提にしています。 JTA トランザクションは、現在のセッションのスコープとコンテキストの両方を定義します。 Hibernate チームは、次のことを主張します。巨大なスタンドアロンの JTA TransactionManager 実装が成熟したら、 J2EE コンテナ上にデプロイされるかどうかにかかわらず、ほとんどの（すべてとは言わないが）アプリケーションが、 JTA トランザクション管理を使用すべきであると。この考えに基づくと、 JTA ベースの「コンテキスト上のセッション」を使うしかないでしょう。

しかし、バージョン 3.1 からは、 SessionFactory.getCurrentSession() の後の処理が、プラガブルになりました。これを受けて、現在のセッションを定義するスコープとコンテキストのプラガビリティを可能にするために、新しい拡張インタフェース ( org.hibernate.context.CurrentSessionContext ) と新しい構成パラメータ ( hibernate.current_session_context_class ) が追加されました。

org.hibernate.context.CurrentSessionContext インタフェースの規約についての詳細な内容は Javadoc を参照してください。それには、 currentSession() という1つのメソッドが定義されており、その実装は、現在の「コンテキスト上のセッション」を追跡することに責任を持ちます。そのまま使えるように、 Hibernate はこのインタフェースの実装を2つ提供しています。

はじめの2つの実装は、「1セッション - 1データベーストランザクション」プログラミングモデルを提供します。これは リクエストごとのセッション（session-per-request） としても知られており、使われています。 Hibernate セッションの開始と終了は、データベーストランザクションの期間で決まります。 JTA を使わない普通の JSE で、プログラム上のトランザクション境界設定を行うなら、コードから基礎のトランザクションシステムを隠蔽するために、 Hibernate Transaction API を使うとよいでしょう。 JTA を使うなら、トランザクションの境界設定には、 JTA インターフェースを使ってください。 CMT をサポートする EJB コンテナで実行するつもりなら、トランザクション境界は宣言的に定義できるため、コード上でトランザクションやセッションの境界を設定する必要はありません。さらに詳細な情報やコードの例は、 章 11. トランザクションと並行性 を参照してください。

hibernate.current_session_context_class 設定パラメータは、 org.hibernate.context.CurrentSessionContext のどの実装を使うかを指定します。下位互換性のため、このパラメータが設定されず org.hibernate.transaction.TransactionManagerLookup が設定されていた場合、 Hibernate は org.hibernate.context.JTASessionContext を使うことに注意してください。通常このパラメータの値には、3つの実装の中から使用する実装クラスの名前を直接指定します。しかし、"jta"、 "thread"、 "managed"というそれぞれの省略名も用意されています。