問題タブ [optimistic-locking]

@versionフィールドを含むエンティティがあります。楽観的ロックの例外にもかかわらず、更新する必要がある場合があります。

その場合、どうにかしてオフにできますか？または、エンティティをリロードして、更新されるまでn回保存を再試行する必要がありますか？

@versionアノテーションを付けた単純なエンティティejbを実装しました。エンティティを更新するたびにバージョン番号が増えると思います。

しかし、これは期待どおりに機能しないようです。また、エンティティを読み取るたびに、バージョン番号が自動的に増加します（！？）。バージョンはコミット後にのみ増加すると思いますか？

読み取りでもバージョンが増える理由を誰かが説明できますか？

JPA 3 をアノテーション (マッピングファイルなし) とプロバイダー org.hibernate.ejb.HibernatePersistence で使用しています

楽観的な同時実行性が必要です。

1) というタグに頼ってみましたが、うまくいきませんでした。

2）だから私はJavaコードでそれを行うことにしました。次のように、mergeServiceRequest メソッドと Request タイプのオブジェクトがあります。トランザクションを開始し、リクエスト オブジェクトをロックしてから、データベースから Request オブジェクト newRequest を取得し、そのタイムスタンプを現在の 1 つのリクエストと比較します。一致しない場合は、例外をスローします。それらが一致する場合、現在のリクエストを現在の時刻で更新し、enter code hereデータベースに保存します。

セッションからトランザクションを開始すると、データベースの行がロックされないため、オブジェクトを手動でロックする必要があります。トランザクションがデータベースのレコードを自動的にロックしないことを示す Java コードをいくつか書きました。

このアプローチの問題はクエリです

常にリクエストと同じオブジェクトを返します。「リクエスト」はセッションentityMangerにあり、クエリは常にセッションにキャッシュされているものを返します。5 つの query.setHint 行をすべて試しましたが、同じ結果が得られます。データベース クエリは実行されず、結果はセッション キャッシュから直接取得されます。

3）だから私は別のセッションを使用しようとしましたが、新しいリクエストを取得すると、新しいリクエストはリクエストとは異なります。しかし、何らかの理由で、そうすると、トランザクションがコミットされた後でも、リクエスト オブジェクトのロックが解放されません。コードは以下のようになります

誰かがこれについて私を助けることができますか?

ありがとう。

ダニエル

マルチテナントアプリケーション用の顧客プロビジョニングツールを構築しています。複数のユーザーが同じ構成で作業できるため、競合を回避したいと考えています。楽観的ロックが進むべき道であることを私たちは知っています。しかし、競合するアクションを実行したユーザーにデルタを表示する方法を知りたいですか？ステータスメッセージを表示するのは簡単ですが、どのデータが競合状態にあるかも表示したいと思います。あなたのアイデアに感謝します。

編集：データはデータベース内のテーブルのセットとして永続化されませんが、XMLファイルに固定化され、それがデータベースに保存されます。

私はRESTfulWebAPIを設計しようとしているので、rfc2616を研究してきました。私は楽観的同時実行性のためにETagを使用するというアイデアが好きで、競合状態なしでリソースを追加する安全な方法を作るためにそれを使用しようとしていました。しかし、セクション14.24で次の2つのステートメントに気づきました。

リクエストがIf-Matchヘッダーフィールドなしで2xxまたは412ステータス以外の結果になる場合は、If-Matchヘッダーを無視する必要があります。

リソース（PUTなど）を更新することを目的としたリクエストには、If-Match値に対応するエンティティ（単一のエンティティタグ）がなくなった場合にリクエストメソッドを適用してはならないことを通知するIf-Matchヘッダーフィールドを含めることができます（MAY）。そのリソースの表現。

私はRDBMSを使用していますが、トランザクションを試すまでトランザクションが正常にコミットされるかどうかわからないため、最初の要件は少し面倒だと思います。誰かがETagが一致しないヘッダーを提供した場合を考えてみましょIf-Matchう。コミットが成功した場合は、ヘッダーに注意しIf-Match、コミットを試みずに412を返す必要があります。コミットが失敗した場合、If-Matchヘッダーのないリクエストは結果として発生します。非2XX/412応答なので、If-Matchヘッダーを無視する必要があります。つまり、コミットを試行する必要があります。

私が理解できる限り、私には2つの選択肢があります。

1. 2フェーズコミットを使用して、コミットを試行する前にコミットが成功するかどうかを予測します。
2. 上記の最初の要件を無視し、無視If-Matchすると2XX/412以外の応答が発生した場合でも412を返します。（これは私が傾いているものです）

他のアイデアはありますか？仕様を誤解していますか？

休止状態とバージョン管理に問題があります。Hibernate 3.6.7-Final を使用しています。これは私の DAO クラスのコード スニペットです (@Transactional アノテーションを使用する Spring Bean によって呼び出されるため、それ自体はトランザクションではありませんが、StaleObjectStateException を強制するためにフラッシュが使用されます)。

バージョンは、次のようにマッピングされた長い値です。

問題は、ユーザーが保存されず、コードが永遠にループすることです。少しデバッグしたところ、hibernate には ActionQueue の概念があり、内部には別のコレクションに挿入、更新などがあることがわかりました。上記のコードのすべてのループで、更新コレクションは 1 ずつ大きくなります。「古い」コレクションであるそのコレクションのインデックス 0 で常に更新を実行しようとするため失敗し、その時点で失敗し、実行されません。更新されたバージョンで更新を実行してみてください。これを機能させる方法はありますか？

おそらく私がやりたいことについての背景があるので、より賢い人がより良い解決策を提案できるかもしれません.バージョン管理がなく、ユーザーが無効なログインカウントを含む列を持っているとします. このカウントは、失敗するたびに 1 ずつ増加し、ログインが成功するとリセットされます。(これを使用して、アカウントへのブルート フォースを防ぐために、x 回失敗した後にユーザーがログインできるようになるまでのタイムアウトを導入しますが、これはここでは関係ありません。) ここで、攻撃者が攻撃を使用するとします。サーバー上の複数のスレッドから同じユーザーアカウントにアクセスできます.2つのスレッドが失敗回数、たとえば2でユーザーを読み取ると、スレッド1がそれを3に更新して保存し、次にスレッド2がそれを3に更新して保存します-失敗した試行が 1 回失われましたが、これはバグです。

したがって、これを修正するために、バージョン管理列を導入したいと思いました。この場合、上記のスレッド 2 によって例外がスローされるという他の目的には役立たず、その場合、操作が再試行されます (潜在的に、しかし高度にありそうにない、ループ内) - 基本的に、これはユーザーを保存するシリアライゼーションを導入しますが、楽観的ロックに基づいています。これは、前述のとおり、機能しません。

誰でもこれで私を助けることができますか? これは始めるのに良い考えですか？多分もっと良い方法がありますか？Hibernate スニペットが機能しないのはなぜですか?

インクリメントカウンターは間接的に操作していlock_versionますか？

lock_version同時実行性に対してテストしていますが、増加していることに気付きました。とはいえ、私はから救助していませんActiveRecord::StaleObjectError。

http://api.rubyonrails.org/classes/ActiveRecord/Locking/Optimistic.htmlによると

これは、自動的increment_counterにレスキューをトリガーすることを意味しますか？ActiveRecord::StaleObjectError

私はこのような方法を持っています：

REQUIRES_NEWトランザクションの伝播と示されている再帰を使用することで、StaleObjectStateExceptionが最終的にクリアされることを期待していましたが、そうではありません。

この例外から回復するにはどうすればよいですか？

私のすべてのアプリケーションは、フィールド レベルのオプティミスティック コンカレンシーを使用しています。

これは、元のデータベース値を追跡し、元の値、更新された値、および現在のデータベース値の間で 3 方向の比較を実行して、(a) ユーザーが更新したものと (b) 他のユーザーが更新したものを決定することによって機能します。

私のアプリケーションでは、フィールドを行にグループ化し、複数のユーザーが同じ行の異なるグループを競合することなく更新できるようにします。

これは、異なる部門が同じレコードの異なるフィールドで作業することがよくあるためです。

EF4.1 は、行全体に基づく非常に基本的な同時実行モデルのみをサポートしているようです! つまり、何もない場合、ユーザーは無限の競合に遭遇します...

組み込みの動作をオーバーライドすることは可能ですか?

永続化のために JPA を使用する単純な EJB アプリケーションを作成しましたが、楽観的ロックが期待どおりに機能しないという問題があります。

Siteこのアプリケーションには、データベース内の SITE という名前のテーブルのモデルを定義するという名前のクラスが含まれています。SITE テーブルには、注釈Siteを使用してクラスで参照される ROW_VERSION という名前の列が含まれています。@version

レコードが更新されるたびに、ROW_VERSION は 1 ずつインクリメントされます。

この問題は、アプリケーションがメソッドを使用して行を読み取ってからEntityManager find、メソッドによって行が更新されるまでの間に行が変更された場合に発生しますEntityManager merge。行の ROW_VERSION が 1 ずつインクリメントされているため、メソッドが呼び出されたときと同じではないため、スローされるEntityManager findと予想OptimisticLockExceptionされますが、代わりに変更がテーブルに書き込まれ、メソッドによって行われた変更が上書きされます。他のプロセス。

アプリケーションは WebSphere 8.5 で実行され、コンテナーによって提供される OpenJPA を使用しています。

楽観的ロックがどのように機能するかを誤解していますか、それともそれを実現するために他に何かする必要がありOptimisticLockExceptionますか?

Site クラスは次のとおりです。

アプリケーションは、ジェネリック DAO ラッパー クラスを使用して EntityManager メソッドを呼び出します。クラスの内容は次のとおりです。

更新- さらに調査を行ったところ、 http://pic.dhe.ibm.com/infocenter/wasinfo/v8r0/index.jsp?topic= %2Fcom.ibm.websphere.nd.multiplatform.doc%が見つかりました。 2Finfo%2Fae%2Fae%2Fcejb_genversionID.htmlしかし、@VersionColumn および @VersionStrategy アノテーションを追加した場合でも、OptimisticLockException をスローすることはできません。