問題タブ [optimistic-locking]

古いデータベース構造では、データを変更すると更新される 1 つのテーブルに 2 つのフィールドがあります。

聞かないでください。それはそうです:-)

現在、Eclipselink と Glassfish v3 を使用して楽観的ロックを実装しています。

@Versionアノテーションを使ってなんとかバージョンアップできました。しかし、名前フィールドが実際に変更された場合にのみ、変更されたフィールドを更新するにはどうすればよいですか。毎回変更されたフィールドを設定するだけで、JPAは毎回行を更新します。名前フィールドに実際の変更がなかったとしても。そして、名前フィールドが本当に「手」で変更されたかどうかを確認したくありません。

@Versionアノテーションを 2 番目のフィールドにも設定できますか?

NHibernate のログ ファイルを確認していたところ、次のようなランダムなエラーが見つかりました。

この問題に関しては、これは楽観的同時実行性が原因で発生し、発生することが「予想される」ことを知っています。私の主な問題はスタック トレースです。「どこで」発生したかはどこにも記載されておらず、行が開始されますNHibernate.Event.Default.AbstractFlushingEventListener.PerformExecution。NHibernate のソース コードをダウンロードして調べてみましたが、完全なスタック トレースが表示されない理由がよくわかりませんでした。同様のエラーのスタック トレースが他にもあり、問題が発生しましたTransaction.Commit()。実際にエラーをスローしているコードを見つける方法はありますか?

SpringのHibernateTemplateを使用してmysqlデータベースにアクセスすると、問題が発生します。シングルスレッド環境では問題なく動作しますが 、マルチスレッドでのOptimisticLockingに関する例外が常にスローされます。

詳細例外は以下のとおりです。

Mapping.Resource_Movieソースコードは次のように表示されます

私はcom.cmcol.Atom.DatabaseTemplateという名前のクラスを作成します。このクラスには、 SpringautowiredからのHibernateTemplateのインスタンスが含まれています。

DatabaseTemplateは他のインスタンスにも自動配線されますが、マルチスレッド環境でのOptimisticLockingに関する問題が発生します。

理由とそれを修正する方法は何ですか？

拡張セッション/自動バージョン管理を使用した標準的な楽観的同時実行制御シナリオで遊んでいます。最初のトランザクションでロードし、変更のためにユーザーに提示し、2番目のトランザクションで保存するエンティティがあり、両方のトランザクションが同じセッションを共有しています。エンティティが何らかの形で 2 番目のトランザクションの最後に変更された後、バージョンの不一致が検出された場合、並行トランザクションがその間にエンティティの次のバージョンを保存したことを意味する session.flush()がスローされる可能性があります。StaleObjectStateException

このようなエラーを最も簡単な方法で処理したいと思います。現在の変更を失うエンティティをリロードし、編集と保存を再度続行するだけです。最初にこれを試しました：

しかし、この更新されたエンティティを変更して保存しようとすると、StaleObjectStateException更新されてバージョン番号が一貫しているように見えても、同じ . refresh()はい、延長セッションでの使用はお勧めできないことは知っていますが、その理由はわかりません。この行動は、それが推奨されない理由に関連していますか?

次に、使用を避けるために次の方法を試しましたsession.refresh()。

しかし、それStaleObjectStateExceptionは実際には古くないエンティティを保存するときに発生します。

例外に対処できた唯一の方法は次のとおりです。

しかし、私の具体的なエンティティに関するものsession.clear()と同じではありませんか?session.evict()

再開するには、私の質問は次のとおりです。

• が行われStaleObjectStateExceptionない限り、リロードされたエンティティでまだスローされるのはなぜですか?session.clear()
• 同じセッションで既にロードされているエンティティをリロードする正しい方法は何ですか?なぜrefresh()悪いのですか? 会話を実装するこのアプローチには何か問題がありますか?

二次キャッシュなしで Hibernate 4.1.7.Final を使用しています。

私の質問が繰り返されている場合は申し訳ありませんが、深い説明を見つけることができません...

楽観的同時実行制御を学習しようとしています。

次のプログラム

1. セッションを開き、テーブルに行を作成します: id=1 name = "raj"、セッションをコミットして閉じます
2. 最初に 3 秒間スリープするスレッドを開始します。次に、session2 を開き、id =1 の人物を name = "raj10" で更新します。その後、session2 が閉じられます。
3. session3 で、同じ db 行 (id=1) を変更します。ただし、この行は、ステップ 2 のスレッドが同じ db 行をロードする前にロードされます。そして、セッション 3 では、ロードされた db 行が更新されます (これは、ステップ 2 のスレッドによって既に変更されているため、古くなります)。だから私はstaleObjectStateExceptionをキャッチします。catch ブロック内で再度読み込み、更新してから保存します。

次の例外が発生します: Exception in thread "main" org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was wrong): [com.raj.hibernate.optimistic.OptPerson#1]

教えてください

1. 新しい値で正常に更新するには、catch ブロックに何を含める必要がありますか。

2. ここで session.merge が役に立ちますか。

   /li>

Tapestry5（java webframework）とHibernateで作成されたWebアプリケーションがあります。今、私は楽観的ロックを追加しようとしています。そこで、バージョン属性を追加し、楽観的ロックが機能するようにしたので、それは簡単で高速でした。

しかし、私のWebアプリケーションは「要求ごとのセッション」パターンで動作するため、この楽観的ロックを利用するための最良の方法がわかりません。

何が起こるのですか：

UserAは、entityA（バージョン1）からの値がロードされたフォームでページを開きます。

UserBは、entityA（バージョン1）からの値がロードされたフォームでページを開きます。

UserAはいくつかの値を変更し、フォームを送信します。->新しいリクエストはentityA（バージョン1）を取得し、変更をコミットします（entityAはバージョン2になりました）

UserBはいくつかの値を変更し、フォームを送信します。->新しいリクエストはentityA（バージョン2）を取得し、変更をコミットします（entityAはバージョン3になりました）

何が起こるべきか

UserBの変更はコミットしないでください。ただし、リクエストごとのセッションパターンのため、Hibernateの楽観的ロックエラーが発生する可能性のある時間枠は、送信からコミットまでの新しいリクエストからの期間に短縮されます。これは望ましい結果ではありません。

可能な解決策

いくつかの調査の後、私は次のことを発見しました：

• エンティティバージョンを使用してフォームに非表示フィールドを追加します

この値を使用して、コミット前にエンティティのバージョンを設定できますが、Hibernateのドキュメントではこの値の設定を推奨していません。また、エンティティがデタッチされて再接続された場合にのみ機能します。それ以外の場合、手動で設定されたバージョン値はHibernateによって無視されるためです。

次に、このバージョン値を使用して、フォームがレンダリングされたときのバージョンが、送信時にリクエストにロードされたエンティティのバージョンと同じであるかどうかを手動で確認できます。次に、必要に応じて自分でOptimisticLockingExceptionをスローします。

• デタッチされたエンティティをHttpSessionに配置するので、送信時に再度ロードする必要はありません。

結論

これらの方法は機能しますが、私にはあまり実用的ではなく、間違いを犯しやすいようです。だから私は他の人がこの問題をどのように実装しているのだろうかと思っています。

OptimisticLockExceptionJavaEE6でをキャッチするための最良の方法は何でしょうか。次のEJBがあります。

そしてこれは私のRESTインターフェースです：

RESTインターフェースでは、すべての例外をキャッチします。さらにOptimisticLockException、ブラウザーからインターフェースを呼び出すと、catch-Blockが実行されないのはなぜですか？

現在、JavaEE 6 のトランザクション処理について勉強していますが、少し行き詰まっています。

誰かがセミナーで 1 人以上の人を予約できるセミナー予約エンジンをシミュレートします。私のエンティティは次のようになります。

これは EJB です。

私のトランザクション リスナーは次のようになります。

問題は、バックエンドで 100 個のスレッドを並行して実行し、次のようなログ エントリを取得していることです。

同じ値の freeCapacity を持つ成功した (コミットされた) トランザクションが存在するのはどうしてでしょうか?

私の意見ではOptimisticLockException、1 番目のトランザクションがエンティティのバージョン フィールドを更新したため、2 番目と 3 番目のトランザクションは をスローする必要があります。したがって、2 番目と 3 番目のトランザクションはロールバックされているはずです。

ここで何かが恋しいですか？どうすればこの問題を解決できますか?

楽観的ロックをサポートするエンティティのテーブル インデックスを定義するためのベスト プラクティスは何ですか?

確かに、ID による高速検索を有効にするには、エンティティ ID を DB のインデックスの一部にする必要があります。バージョン列はどうですか？それをインデックスの一部にすることは理にかなっていますか?

DB の主キーを定義せず、エンティティ ID + バージョン列からなるインデックスを作成するとどうなるでしょうか。同じエンティティ ID を持つ DB に 2 つの行があるリスクはありますか? 2 つのトランザクションが、同じエンティティ ID を持つ 2 つのエンティティを並行して維持するとしますか?

これらのメモを読んでください。EBeanサイトページ。以下を含む段落があります：

「EJB3コンテナでEntityManagerを管理する自然な方法は、ステートフルセッションBeanを使用することです。」

また、次のような公開された問題がありました

「「ユーザー思考時間」中にEntityManagerを管理する方法は？

したがって、質問：「user-think-time」に関する前述の問題を解決できるEJBステートレスBeanは何を実行/提供しますか？

ejbは「セッション管理」を提供していると思いますが、セッションをThredLocal変数に格納し、オンデマンドでユーザーに提供する場合の問題は何ですか？そして、EJBを使用しないでください。ejbにはこれに対するワンストップソリューションがありますか？

つまり、この記事には次のように書かれています。この問題のために、Session（休止状態）またはEntityManagerの概念を使用するのは悪いことです。つまり、EJBステートレスBeanを使用する場合、またはセッション管理メカニズムを自分で提供できる場合（実装が難しいと思われる場合）を除いて、これを使用する必要はまったくありません。