第5章 トランザクションおよび並行性

最初に entitymanager-per-operation アンチパターンを使用しないでください。つまり、単一スレッドで各単一データベースコールに対して EntityManager をオープンおよびクローズしないでください。当然、これはデータベーストランザクションにも当てはまります。アプリケーションのデータベースコールは、計画された順序で行われます。これらのコールはアトミックな作業単位にグループ分けされます (これは、各単一 SQL ステートメント後の自動コミットがアプリケーションで役に立たないことを意味します。このモードはアドホック SQL コンソール作業で使用することを目的としています)。

マルチユーザークライアント/サーバーアプリケーションの最も一般的なパターンは entitymanager-per-request です。このモデルでは、クライアントからの要求はサーバー (JPA 永続レイヤーが実行される) に送信され、新しい EntityManager がオープンされ、すべてのデータベース操作がこの作業単位で実行されます。作業が完了すると (および、クライアントの応答が準備されると)、永続コンテキストとエンティティマネージャがフラッシュされ、クローズされます。また、クライアント要求を処理するために単一のデータベーストランザクションも使用します。2 つの関係は 1 対 1 であり、このモデルは多くのアプリケーションに完全に適合します。

これは、Java EE 環境のデフォルトの JPA 永続モデル (JTA バインドされた、トランザクションスコープ対象の永続コンテキスト) です。挿入 (または検索) されたエンティティマネージャは特定の JTA トランザクションの同じ永続コンテキストを共有します。JPA の利点は、これについて考慮しなくてもよいことであり、エンティティマネージャと、完全に直交するセッション Bean 上のトランザクションスコープの境界からデータアクセスを参照します。

難点は、JPA コンテナ外部の本 (および他の) 動作の実装です。EntityManager とリソースローカルトランザクションを適切に開始および終了する必要があるだけでなく、これらはデータアクセス操作に対してアクセス可能である必要があります。作業単位の境界は、理想的には要求が非 JPA コンテナサーバーに届いたときに (応答が送信される前 (つまり、スタンドアロンサーブレットコンテナを使用する場合は ServletFilter)) 実行されるインターセプタを使用して実装されます。ThreadLocal 変数を使用して要求を処理するスレッドに EntityManager をバインドすることをお薦めします。これにより、このスレッドで実行されるすべてのコードでアクセスが容易になります (静的変数へのアクセスと同様)。選択したデータベーストランザクション境界メカニズムに応じて、トランザクションコンテキストを ThreadLocal 変数に保持することもできます。この実装パターンは Hibernate コミュニティでは ThreadLocal Session および Open Session in View として知られています。Hibernate リファレンスドキュメンテーションに記載された HibernateUtil を簡単に拡張し、このパターンを実装できます。外部ソフトウェアは必要ありません (これは実際には重要なことではありません)。当然、使用している環境でインターセプタを実装し、設定する方法を見つける必要があります。ヒントと例については、Hibernate Web サイトを参照してください。もう一度述べますが、最初の選択肢は JPA コンテナ (理想的には JBoss アプリケーションサーバーなどの軽量でモジュール形式のもの) です。

entitymanager-per-request パターンは作業単位を設計する場合にのみ役に立つコンセプトです。多くのビジネスプロセスはデータベースアクセスでインターリーブされたユーザーとの全体の対話を必要します。Web とエンタープライズアプリケーションでは、データベーストランザクションで要求間の待機時間が長いユーザー対話に対応できません。以下の例を考えてください。

ユーザーの観点からこの作業単位は長く実行されているアプリケーショントランザクションと呼ばれます。アプリケーションでこれを実装するには多くの方法があります。

最初のナイーブな実装では、ユーザーが考えている間に、同時の変更を防ぎ、分離と原子性を確保するためにデータベースでロックが保持された状態で EntityManager とデータベーストランザクションがオープンのままに場合があります。当然これは、ロックの競合によりアプリケーションが複数の同時ユーザーに対応できなくなるため、アンチパターンであり、ペシミスティックなアプローチです。

当然、アプリケーショントランザクションを実装するには複数のデータベーストランザクションを使用する必要があります。この場合、ビジネスプロセスの分離の維持について、一部はアプリケーション層の責任になります。単一アプリケーショントランザクションには、通常複数のデータベーストランザクションが関係します。これは、これらのいずれかのデータベーストランザクション (少なくとも 1 つ) が更新データを保持し、他のすべてが単にデータを読み取る場合 (複数の要求/応答サイクルにわたるウィザード形式のダイアログなど) にのみ原子的になります。これは、思ったよりも簡単に実装できます (特に、JPA エンティティマネージャと永続コンテキスト機能を使用する場合)。

entitymanager-per-request-with-detached-objects と entitymanager-per-application-transaction には利点と欠点があります。これらについては、この章の後半のオプティミスティック並行性制御のコンテキストで説明します。

アプリケーションは 2 つの異なる永続コンテキストの同じ永続ステータスに同時にアクセスできます。ただし、管理対象クラスのインスタンスは 2 つの永続コンテキスト間で共有されません。したがって、ID には 2 つの異なる表記法があります。

特定の永続コンテキスト (つまり、EntityManager のスコープ内) にアタッチされたオブジェクトの場合は、2 つの表記法が同じになり、データベース ID の JVM ID が Hibernate Entity Manager によって保証されます。ただし、アプリケーションが 2 つの異なる永続コンテキストの「同じ」(永続 ID) ビジネスオブジェクトに同時にアクセスできる一方で、2 つのインスタンスは実際には異なります (JVM ID)。競合はフラッシュ/コミット時に自動バージョン機能とオプティミスティックアプローチを使用して解決されます。

このアプローチでは Hibernate とデータベースで並行性について考える必要があります。単一スレッドの作業単位で ID を保証する場合はコストがかかるロックや他の同期手段を必要としないため、最適なスケーラビリティが提供されます。EntityManager ごとの単一スレッドを使用し続ける限り、アプリケーションはビジネスオブジェクトを同期する必要がありません。永続コンテキスト内で、アプリケーションはエンティティを比較するために == を安全に使用できます。

ただし、永続コンテキスト外で == を使用するアプリケーションは、予期しない結果をもたらす場合があります。これは、予期しない場合 (2 つのデタッチ済みインスタンスを同じ Set に配置した場合など) に起こることがあります。両方は同じデータベース ID を持つことができます (つまり、同じ行を表す) が、JVM ID は定義により、デタッチ済みの状態のインスタンスに対して保証されません。開発者は永続クラスの equals() メソッドと hashCode() メソッドをオーバーライドし、オブジェクトの同一性を表す独自の表記法を実装する必要があります。1 つ注意点があります。同一性を実装するためにデータベース ID を使用しないでください。ビジネスキーと、一意の通常は変更不可の属性の組み合わせを使用してください。データベース ID は一時エンティティが永続的になた場合に変わります (persist() 操作のコントラクトを参照)。一時インスタンス (通常は、デタッチ済みのインスタンスとともに使用) が Set で保持された場合は、ハッシュコードを変更すると、 Set のコントラクトが破棄されます。適切なビジネスキーの属性はデータベースプライマリキーほど安定的である必要がなく、オブジェクトが同じ Set に含まれる場合にのみ、安定性を保証する必要があります。この問題の詳細については、Hibernate Web サイトを参照してください。また、これは Hibernate の問題ではなく、単に Java オブジェクト ID と同一性の実装方法の問題であることに注意してください。

アンチパターン entitymanager-per-user-session または entitymanager-per-application (当然、このルールの例外はほとんどありません。たとえば、デスクトップアプリケーションでは、永続コンテキストを手動でフラッシュして entitymanager-per-application を使用できます)。以下のいくつかの問題には推奨するパターンが存在します。設計を決定する前に結果について理解してください。