１つ目は、session-per-operation アンチパターンを使ってはいけません。 すなわち、１つのスレッドの中で、単純なデータベース呼び出しのたびに Session を開いて、閉じてはいけません！ もちろん、データベーストランザクションについても同様です。 アプリケーション中のデータベース呼び出しは、 計画されたシーケンス（planned sequence）を使い、 アトミックな作業単位に分類されます。 （１つのSQL文ごとにコミットする自動コミットが、 使われないという意味でもあることに注意してください。 自動コミットは、SQLコンソールでアドホックな作業をする際に使うものです。 Hibernateは直ちに自動コミットモードを無効にします。 もしくは、アプリケーションサーバーが無効化することを期待します。） データベーストランザクションはオプションではありません。 データベースとのすべての通信は、データの読み込みであっても、書き込みであっても、 トランザクションの中で行わなければなりません。 説明すると、データ読み込みに対して、自動コミットは避けるべきです。 なぜなら、多数の小さなトランザクションは、明確に定義された１つの作業単位と比べて、 パフォーマンスがよくなることはありません。 後者は保守性や拡張性もよりすぐれています。

マルチユーザーのクライアント／サーバーアプリケーションの中で、 最もよく使われるパターンは、session-per-request です。 このモデルの中では、 クライアントから（Hibernate永続化層が動作する）サーバーへリクエストが送られ、 新しいHibernate Session が開かれます。 そして、この作業単位の中ですべてのデータベース処理が実行されます。 作業が完了した（そして、クライアントへのレスポンスが準備できた）時点で、 session をフラッシュし、閉じます。 クライアントの要求を処理するために、１つのデータベーストランザクションを使用するでしょう。 Session を開き、閉じる際に、 データベーストランザクションを開始し、コミットします。 二つの関係は一対一です。 このモデルは多くのアプリケーションに完全に適合します。

以降の実装にチャレンジしてください。 Session を持ち、トランザクションを正確に開始し、終わらせるだけでなく、 データアクセス操作も得やすくする必要があります。 リクエストがサーバーにヒットした際と、レスポンスを送信する前に、実行されるinterceptor （例えば、ServletFilter）を使って、作業単位の境界を実装するのが理想的です。 ThreadLocal 変数を使って、 リクエストを処理するスレッドに Session を結びつけることを推奨します。 これにより、スレッド内で実行されるすべてのコードで、 （static変数にアクセスするように）簡単に Session にアクセスできるようになります。 選択したデータベーストランザクション境界の機構次第で、ThreadLocal 変数の中にトランザクションコンテキストを保持するかもしれません。 この実装パターンは、ThreadLocal Session および Open Session in View という名前で知られています。 本ドキュメントで先に見せた HibernateUtil ヘルパークラスを拡張することで、 このパターンを容易に実装できます。 もちろん、interceptor を実装する方法を見つけ、環境をセットアップする必要があります。 HibernateのWebサイトにあるtipsと例を参照してください。

以降の実装にチャレンジしてください。 Hibernateは単純なこのパターンのために、予め組み込まれた 「current session」の管理を提供します。 サーバーリクエストを処理する際はトランザクションを開始しなければなりません。 そして、レスポンスをクライアントに送信する前にトランザクションを終わらせます。 好きな方法で実現できます。一般的な解決策は ServletFilter や サービスメソッドをポイントカットしてAOPインターセプター、 proxy/interception コンテナです。 EJBコンテナはEJBセッションビーンをトランザクション境界として アスペクトをクロスカットする実装の標準的な方法です（CMTによる宣言的）。 プログラムによるトランザクション境界を使うと決めた場合、 簡単に使うため、互換性のあるコードにするために、 この章の後のほうにあるHibernate Transaction APIのほうがよいです。

アプリケーションのコードは、必要なときにどこでも、何回でも、 単に sessionFactory.getCurrentSession() を呼び出すだけで 「現在のセッション」にアクセスできます。 現在のデータベーストランザクションへの セッション を常に取得します。 リソース・ローカルな環境、もしくはJTA環境を構成しなければなりません （項2.5. 「コンテキスト上のセッション」 を参照してください）。

ときどき、「ビューを描画する」まで セッション とデータベーストランザクションのスコープを拡張すると便利なことがあります。 これは、要求の処理と描画のフェーズを分けている サーブレットアプリケーションにおいて特に役立ちます。 独自のインターセプタを実装すれば、 ビューを描画するまでデータベーストランザクションを拡張するのは簡単です。 しかし、コンテナ管理トランザクションのEJBに頼る場合は、簡単にはできません。 なぜなら、ビューの描画を開始する前に、EJBのメソッドがリターンした際に、 トランザクションが完了するためです。 この Open Session in View パターンに関連するヒントと例については、 HibernateのWebサイトやフォーラムを参照してください。

session-per-requestパターンは、作業単位を設計する際に役立つ考えというだけではありません。 多くのビジネスプロセスは、ユーザーとの一連の相互作用全体を要求します。 その相互作用には、データベースアクセスが含まれます。 Webとエンタープライズアプリケーションでは、データベーストランザクションが ユーザとの相互作用にまで渡ることは許されません。 次の例をよく考えてみてください。

この作業単位を（ユーザーの視点で）長期の 対話 （もしくは、アプリケーショントランザクション ）と呼びます。 アプリケーションにこれを実装する方法はたくさんあります。

最初に思いつく実装は、ユーザーが考えている間、Session とデータベーストランザクションを開いたままにしておくことです。 同時に修正されず、分離と原子性が保証されるように、 データベース内のロックは保持したままにします。 もちろん、これはアンチパターンです。 なぜなら、ロックの競合が発生すると、 アプリケーションが同時ユーザー数に応じてスケールアップできなくなるからです。

明らかに、対話を実装するためには、 いくつかのデータベーストランザクションを使用するべきです。 この場合、ビジネスプロセスの分離を維持することは、 アプリケーション層の責務の１つになります。 １つの対話は、 通常いくつかのデータベーストランザクションに及びます。 データベーストランザクションの１つのみ（最後の１つ）が更新したデータを保存し、 他はデータを読むだけであれば、それはアトミックです （例えば、いくつかの要求／応答を繰り返すウィザード形式のダイアログ）。 これは聞くより、実装したほうが簡単です。 Hibernateの機能を使うのであれば、特に簡単です。

session-per-request-with-detached-objects と session-per-conversation の２つは、 利点と欠点を持っています。 これについては、この章の後のほうで、楽観的同時実行制御の文脈の中で議論します。

アプリケーションは、２つの異なる Session から 同じ永続状態に同時にアクセスできます。 しかし、２つの Session インスタンスが 永続性クラスの１つのインスタンスを共有することはできません。 ゆえに、識別子には２つの異なる概念があるということになります。

個々の Session に追加されたオブジェクトにとって （すなわち、１つの Session のスコープの中では）、２つの概念は同じです。 データベース同一性とJVM同一性が一致することを、Hibernateが保証します。 しかし、アプリケーションが２つの異なるセッションから 「同じ」（永続性識別子の）ビジネスオブジェクトに同時にアクセスする限り、 ２つのインスタンスは実際に（JVM識別子が）「異なり」ます。 楽観的アプローチによって、（自動バージョニングの）フラッシュ／コミット時に コンフリクトが解決されます。

このアプローチでは、Hibernateとデータベースに同時実行についての心配が残ります。 一方で、最高のスケーラビリティが提供されます。 なぜなら、１スレッドの作業単位の中で一意性が保証されれば、 高価なロックや同期化が不要になるためです。 Session ごとに１つのスレッドを貼り付ける限り、 アプリケーションはビジネスオブジェクトをsynchronizeする必要はありません。 Session 内では、アプリケーションはオブジェクトを比較するために、 == を安全に使用できます。

けれども、Session の外で == を使うアプリケーションは、予期しない結果に遭遇します。 これは予期しない場所で起こりえます。 例えば、２つの分離インスタンスを同じ Set に putしたときなどです。 両方とも同じデータベース識別子を持ちます（すなわち、同じ行を表します）。 しかし、分離状態のインスタンスのJVM識別子は当然保証されません。 開発者は、永続性クラスの equals() と hashCode() メソッドをオーバーライドし、オブジェクト等価性の概念を実装すべきです。 警告が１つあります。等価性の実装にデータベース識別子を使わないでください。 ユニークな（普通は不変の）属性の組み合わせであるビジネスキーを使ってください。 もし、一時オブジェクトが永続化された場合、データベース識別子が変わります。 一時オブジェクトを（通常分離インスタンスと共に） Set に保持する場合、ハッシュコードが変わるということは、Set の契約を破るということです。 ビジネスキーのための属性は、データベースの主キーほど安定すべきではないです。 オブジェクトが同じ Set の中にいる間だけ、安定を保証すべきです。 この問題のより徹底的な議論は、HibernateのWebサイトを参照してください。 また、これはHibernateの問題ではなく、単にJavaオブジェクトの識別子や等価性を どのように実装すべきかということです。

session-per-user-session と session-per-application アンチパターン は使ってはいけません（もちろん、まれに例外があります）。 注意：下記の問題のいくつかは、推奨されるパターンとしても出現します。 設計を決定する前に、裏の意味を理解するようにしてください。

Hibernate永続化層を管理されていない環境で実装する場合は、 通常単純なコネクションプール（すなわちDataSourceではない）によって、 データベースコネクションを制御します。 Hibernateはそのコネクションプールから必要なコネクションを取得します。 セッション／トランザクション制御のイディオムは次のようになります。

// Non-managed environment idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // do some work
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

明示的に Session の flush() を呼び出すべきではなく、 commit() を呼び出すことにより、自動的に同期化処理が実行されます （セッションの 項10.10. 「セッションのフラッシュ」 に依存している）。 close() を呼び出すことにより、セッションの終わりを明確にします。 close() が暗黙的に行う主なことは、 セッションがJDBCコネクションを開放することです。 上記のJavaコードはポータブルであり、管理されていない環境とJTA環境の両方で実行できます。

より適応性のある解決策は、Hibernateに予め組み込まれている 「current session」コンテキスト管理です。 言葉で説明するより下記を見たほうが速いでしょう。

// Non-managed environment idiom with getCurrentSession()
try {
    factory.getCurrentSession().beginTransaction();

    // do some work
    ...

    factory.getCurrentSession().getTransaction().commit();
}
catch (RuntimeException e) {
    factory.getCurrentSession().getTransaction().rollback();
    throw e; // or display error message
}

正規のアプリケーションの中では、このようなコードの切れ端を決して見ないでしょう。 致命的な（システム）例外は、常に「最上位」でキャッチすべきです。 言い換えれば、（永続化層で）Hibernate呼び出しを実行するコードと、 RuntimeException を制御する （通常はクリーンアップと終了のみ行うことができる）コードは、別々の層の中にあります。 Hibernateによるカレントコンテキスト管理は、この設計をかなり単純にします。 必要なのは、SessionFactory にアクセスすることだけです。 例外処理は、この章の後のほうで議論します。

注意：（デフォルトですが） org.hibernate.transaction.JDBCTransactionFactory を選択するべきです。 第2の用例としては、 hibernate.current_session_context_class を "thread" とするとよいでしょう。

永続化層をアプリケーションサーバー（例えば、EJBセッションBeanの背後）で実行する場合、 Hibernateから取得するすべてのデータソースコネクションは、 自動的にグローバルJTAトランザクションの一部になります。 EJBを使わずに、スタンドアロンのJTA実装を導入することもできます。 JTA統合のために、Hibernateは２つの戦略を提供します。

Bean管理トランザクション（BMT）を使い、Transaction APIを使う場合、 HibernateはアプリケーションサーバーにBMTトランザクションの開始と終わりを告げます。 すなわち、トランザクション管理のコードは、管理されない環境と同じになります。

// BMT idiom
Session sess = factory.openSession();
Transaction tx = null;
try {
    tx = sess.beginTransaction();

    // do some work
    ...

    tx.commit();
}
catch (RuntimeException e) {
    if (tx != null) tx.rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

トランザクション境界として Session を使いたい場合、 簡単にコンテキストを伝播する機能である getCurrentSession() があるので、 JTAの UserTransaction APIを直接使用すべきでしょう。

// BMT idiom with getCurrentSession()
try {
    UserTransaction tx = (UserTransaction)new InitialContext()
                            .lookup("java:comp/UserTransaction");

    tx.begin();

    // Do some work on Session bound to transaction
    factory.getCurrentSession().load(...);
    factory.getCurrentSession().persist(...);

    tx.commit();
}
catch (RuntimeException e) {
    tx.rollback();
    throw e; // or display error message
}

CMTでは、トランザクション境界をセッションBeanのデプロイメントディスクリプタで定義し、 プログラムでは行いません。 ゆえに、コードは次のように少なくなります。

// CMT idiom
 Session sess = factory.getCurrentSession();

 // do some work
 ...

CMT/EJBの中では、常にロールバックが自動的に実施されます。 なぜなら、セッションビーンのメソッドにより投げられた制御されていない RuntimeException は、グローバルトランザクションを ロールバックするようにコンテナに伝えるためです。 これは、BMTもしくはCMTといっしょにHibernate Transaction APIを使う必要は少しもないという意味です。

Hibernateのトランザクションファクトリを設定する際に、 JTAを直接使う（BMTの）場合は org.hibernate.transaction.JTATransactionFactory を、 CMTセッションビーンの中では org.hibernate.transaction.CMTTransactionFactory を 選択すべきだということに注意してください。 hibernate.transaction.manager_lookup_class をセットすることも思い出してください。 なお、hibernate.current_session_context_class は、 セットしないか（後方互換）、"jta" をセットしてください。

getCurrentSession() オペレーションは、JTA環境では１つの欠点を持ちます。 デフォルトで使われる after_statement コネクションリリースモードを使用する上で、 警告が１つあります。 JTA仕様の愚かな制約のために、 scroll() または iterate() が返した、 閉じられていない ScrollableResults または Iterator インスタンスをHibernateが自動的にクリーンアップすることはできません。 finally ブロックの中で、 ScrollableResults.close() または Hibernate.close(Iterator) を明示的に呼び出して、 裏に潜んだデータベースカーソルを解放 しなければなりません。 （もちろん、多くのアプリケーションでは、JTAかCMTコードで scroll() や iterate() の使用を避けるのは容易です。）

Session が例外（SQLExceptionを含む）を投げた場合、 直ちに、データベーストランザクションをロールバックし、Session.close() を呼び、Session インスタンスを破棄すべきです。 Session のいくつかのメソッドは、 セッションの状態を 矛盾したまま にします。 Hibernateが投げた例外を、回復できるものとして扱うことはできません。 finally ブロックの中で close() を呼んで、 Session を確実に閉じてください。

HibernateException は、Hibernate永続化層の中で発生する多くのエラーを ラップする、検査されない例外です（Hibernateの古いバージョンは違いました）。 私たちの意見は、アプリケーション開発者に回復不可能な例外を 下層でキャッチすることを強要すべきではないということです。 多くのシステムでは、検査されない例外と致命的な例外は、 コールスタックの最初のフレームの１つ（例えば、最上位の層で）でハンドリングし、 エラーメッセージをアプリケーションユーザーに表示します （もしくは、他の適切な処理を実施します）。 Hibernateは、HibernateException 以外の検査されない例外も 投げることに注意してください。 これらもまた、回復不可能であり、適切な処理を実施すべきです。

Hibernateは、データベースとの対話中に投げられた SQLException を JDBCException でラップします。 実は、例外をより意味のある JDBCException のサブクラスに 変換しようと試みます。 元の SQLException は、JDBCException.getCause() によりいつでも得られます。 Hibernateは、SessionFactory に追加されている SQLExceptionConverter を使い、SQLException を 適当な JDBCException サブクラスに変換します。 デフォルトでは、SQLExceptionConverter は設定されているSQL方言により 定義されます。 一方で、独自の実装に差し替えることもできます （詳細は、SQLExceptionConverterFactory クラスのJavadocを参照してください）。 標準的な JDBCException のサブタイプを下記に示します。

EJBのような管理された環境が提供するきわめて重要な特徴の１つは、 トランザクションのタイムアウトです。 これは管理されていないコードには提供できません。 トランザクションタイムアウトは、不品行なトランザクションが ユーザーにレスポンスを返さないまま、無期限にリソースを使い続けない ことを保障します。 管理された環境（JTA）の外では、Hibernateはこの機能をフルに提供できません。 しかしながら、Hibernateは次のようなデータアクセス操作の制御くらいはできます。 データベースレベルのデッドロックや大きなリザルトセットを返すクエリを 定義されたタイムアウトによって確実に制限します。 管理された環境では、HibernateはトランザクションタイムアウトをJTAに委譲します。 この機能は、Hibernateの Transaction オブジェクトに よって抽象化されています。

Session sess = factory.openSession();
try {
    //set transaction timeout to 3 seconds
    sess.getTransaction().setTimeout(3);
    sess.getTransaction().begin();

    // do some work
    ...

    sess.getTransaction().commit()
}
catch (RuntimeException e) {
    sess.getTransaction().rollback();
    throw e; // or display error message
}
finally {
    sess.close();
}

CMTビーンの中では setTimeout() を 呼び出せないことに注意してください。 トランザクションタイムアウトは宣言的に定義されるべきです。

Hibernateにほとんど助けてもらわずに実装するケースです。 データベースとのやり取りは、それぞれ新しい Session の中で起こります。 開発者は、すべての永続性インスタンスを操作する前に、 データベースから再読み込みする責務があります。 このアプローチでは、対話トランザクションの分離を守るために、 アプリケーション自身がバージョンチェックを行う必要があります。 このアプローチは、データベースアクセスの中では、最も非効率です。 エンティティEJBと最も似ているアプローチです。

// foo is an instance loaded by a previous Session
session = factory.openSession();
Transaction t = session.beginTransaction();

int oldVersion = foo.getVersion();
session.load( foo, foo.getKey() ); // load the current state
if ( oldVersion!=foo.getVersion ) throw new StaleObjectStateException();
foo.setProperty("bar");

t.commit();
session.close();

<version> を使って、version プロパティをマッピングします。 Hibernateは、エンティティがダーティである場合、フラッシュし、 その間に version プロパティを自動的にインクリメントします。

もちろん、データの並列性が低い環境で運用しており、バージョンチェックが不要なら、 このアプローチを使い、バージョンチェックをスキップするだけです。 その場合は、長い対話には、 「最後にコミットしたものが勝つ」 がデフォルトの戦略でしょう。 このアプローチは、アプリケーションのユーザーを混乱させるかもしれないことを 心に留めて置いてください。それは、エラーメッセージや競合した変更をマージする機会が ないまま、更新を失う経験をするためです。

確かに、マニュアルによるバージョンチェックは、些細な儀式だけで実行できますが、 多くのアプリケーションにとって実用的ではありません。 しばしば、１つのインスタンスだけでなく、 修正されたオブジェクトの完全なグラフをチェックしなければなりません。 Hibernateは、設計パラダイムとして、拡張 Session か 分離されたインスタンスを自動的にバージョンチェックします。

１つの Session インスタンスとその永続性インスタンスは、 session-per-conversation として知られる、 対話全体で使われます。 Hibernateはフラッシュする際に、インスタンスのバージョンをチェックします。 同時に修正されたことを検出すると、例外を投げます。 この例外をキャッチして扱うのは、開発者の責任です （一般的な選択肢は、変更をマージするか古くないデータでビジネス対話を 再スタートする機会をユーザーに提供することです）。

ユーザーの対話を待っているときは、 Session を基礎となるJDBCコネクションから切り離します。 このアプローチは、データベースアクセスの中では、最も効率的です。 アプリケーションは、バージョンチェックや分離されたインスタンスを再追加すること に関心を持つ必要はありません。また、あらゆるデータベーストランザクションの中で インスタンスを再読み込みする必要はありません。

// foo is an instance loaded earlier by the old session
Transaction t = session.beginTransaction(); // Obtain a new JDBC connection, start transaction

foo.setProperty("bar");

session.flush();    // Only for last transaction in conversation
t.commit();         // Also return JDBC connection
session.close();    // Only for last transaction in conversation

foo オブジェクトは、自分をロードした Session をまだ知っています。 古いセッションの上で新しいデータベーストランザクションを開始することで、 新しいコネクションを取得し、そのセッションが再開されます。 データベーストランザクションをコミットすることで、 セッションからJDBCコネクションを切断し、コネクションをプールに返します。 再接続した後、更新していないデータのバージョンチェックを強制するために、 他のトランザクションにより更新されているかもしれないオブジェクトに関して、 LockMode.READ をつけて Session.lock() を呼び出すことができます。 更新して いる データをロックする必要はありません。 通常、拡張 Session に FlushMode.NEVER をセットします。 最後のデータベーストランザクションの周期でのみ、 対話の中で変更されたすべてを実際に永続化させるためです。 ゆえに、最後のデータベーストランザクションのみ flush() オペレーションを含みます。そして、対話を終わらせるために、 セッションも close() します。

ユーザーが考慮中に、格納することができないくらい Session が大きいのであれば、このパターンは問題があります。 例えば、HttpSession は可能な限り小さく保つべきです。 Session は（強制的に）１次キャッシュでもあり、 ロードしたオブジェクトをすべて保持します。 おそらく、リクエスト／レスポンスのサイクルが数回であれば、この戦略が使えます。 １つの対話のためだけに Session を使うべきです。 なぜなら、すぐに新鮮でないデータを持つためです。

（Hibernateの以前のバージョンは、明示的な Session の 切断と再接続が必要だったことに注意してください。 これらのメソッドは非推奨になりました。 なぜなら、トランザクションの開始と終了は同じ効果があるためです。）

切断した Session を永続化層の近くで保持すべきであることに 注意してください。 言い換えると、３層環境の中で Session を保持するために、 EJBステートフルセッションBeanを使ってください。 HttpSession に格納するために、Web層に転送しないでください （別の層へのシリアライズもしないでください）。

拡張セッションパターン（もしくは、session-per-conversation）は、 自動的なカレントセッションコンテキスト管理を実施するより難しい。 このために、あなたは CurrentSessionContext の実装を供給する必要があります。 Hibernate Wikiにある例を参照してください。

新しい Sessionにより、永続化ストア（訳注：ＤＢ）との対話が発生します。 また一方、同じ永続性インスタンスが、データベースとの対話ごとに再利用されます。 アプリケーションは、元々は他の Session でロードされ、 デタッチされたインスタンスの状態を操作します。 そして、Session.update() もしくは、Session.saveOrUpdate()、 Session.merge() を使って、それらのインスタンスを再追加します。

// foo is an instance loaded by a previous Session
foo.setProperty("bar");
session = factory.openSession();
Transaction t = session.beginTransaction();
session.saveOrUpdate(foo); // Use merge() if "foo" might have been loaded already
t.commit();
session.close();

この場合もやはり、Hibernateはフラッシュする際に、インスタンスのバージョンをチェックします。 更新の競合が発生した場合には、例外を投げます。

オブジェクトが修正されていないことを確信している場合は、 update() の代わりに、LockMode.READ を使って、 lock() を呼び出すこともできます （すべてのキャッシュを迂回し、バージョンチェックを実施します）。

マッピングの optimistic-lock 属性に false を設定することにより、特定のプロパティやコレクションのために 自動バージョンインクリメントを無効にできます。 プロパティがダーティであっても、バージョンをインクリメントしません。

レガシーのデータベーススキーマは、しばしば固定的であり、変更できません。 または、他のアプリケーションが同じデータベースにアクセスしなければならず、 そのアプリケーションはバージョン番号やタイムスタンプさえ操作する方法を知りません。 どちらの場合も、テーブルの特定のカラムを当てにして、バージョニングを行えません。 バージョンやタイムスタンプのプロパティをマッピングせずに、バージョンチェックさせるために、 <class> マッピングに optimistic-lock="all" を 指定してください。 行のすべてのフィールドの状態を比較するようになります。 これは、Hibernateが古い状態と新しい状態を比較できる場合に、 理論的に動作するだけであることに注意してください。 例えば、session-per-request-with-detached-objects ではなく、 １つの長い Session を使う場合です。

ときどき、行われた変更が重ならない限り、同時に行われた変更を受け入れることができます。 <class> マッピングに optimistic-lock="dirty" を設定した場合、フラッシュする際に、Hibernateはダーティフィールドのみを比較します。

専用のバージョン／タイムスタンプのカラムを使う場合、 もしくはすべて／ダーティのフィールドを比較する場合どちらであっても、 Hibernateはエンティティごとに1つの UPDATE 文を （適切な WHERE 節と共に）使い、 バージョンチェックと情報の更新を行います。 関連するエンティティの再追加をカスケードするために、 連鎖的な永続化を使用した場合、不必要な更新を実行するかもしれません。 これは通常問題になりません。 しかし、分離したインスタンスを変更していなくとも、 データベースの on update トリガーが実行されるかもしれません。 <class> マッピングに select-before-update="true" を設定することによって、 この振る舞いをカスタマイズできます。 確実に変更されたかを確認するために、行を更新する前に、 必ずインスタンスを SELECT します。