問題タブ [optimistic-concurrency]

オプティミスティック コンカレンシー チェックのために ConcurrencyMode が "Fixed" に設定された整数プロパティ (ROW_VERSION という名前) を持つエンティティ クラスがあります。このタイプのエンティティを保存する前に、アプリケーション コードでこの列の値をインクリメントします (そのため、StoreGeneratedPattern は None に設定されます)。これは、変更を保存するときにうまく機能します。

ここで、以前に読み込まれたエンティティ (ROW_VERSION = x) があり、新しい DbContext を作成し、このエンティティをアタッチして、このエンティティを含むクエリを発行したときに、同時実行エラーを検出したいと考えています。問題は、ROW_VERSION が別のクライアント アプリケーションによってインクリメントされた場合 (ROW_VERSION = x + 1)、クエリ中にこれが検出されないことです。これは、添付されたエンティティの値が明らかに優先されるためです (これは、一般的な列の値に対して完全に意味があります)。 ）。

一方、並行性チェック列の場合、EF が値を現在のデータベース値で更新すると、期待値と比較できるので便利です。または、クエリの実行からスローされた例外が許容されます。

.NET 4.0 でエンティティ フレームワーク 4.3 を使用しています。

編集 (Gert Arnold からのコメントに応じて):

私は自分の問題をもう少し明確にしようとします...

私のアプリケーションが一般的にどのように機能するかについてのメモ:

• 使用可能なエンティティ オブジェクトを表示するツリービューがあり、いずれかを選択すると、完全なエンティティが DB から読み込まれ、編集可能な詳細ビューに表示されます。

• エンティティ オブジェクトへの変更はすぐには保存されませんが、メモリにキャッシュされるため、ユーザーが保存ボタンを押すと、さまざまなエンティティ オブジェクトの変更が蓄積され、まとめて保存されます。

• DbContext は、クエリと変更の保存用に別々に作成されます (つまり、常に同じ DbContext を持っているわけではありませんが、必要に応じてインスタンス化されます)。

• 詳細ビューに表示するためにエンティティ オブジェクトが読み込まれると、以前に変更された (キャッシュされた) すべてのエンティティ オブジェクトが、最初にクエリに使用される DbContext にアタッチされます。次に、実際のクエリが発行されます。そのため、エンティティ オブジェクトをクエリすると、データベースからのバージョンではなく、結果として変更されたバージョンが取得される前に変更されました (その間に変更された可能性があります)。

だからここに私の問題を示す例があります:

1. クライアント アプリ 1 は、ROW_VERSION = 1 でエンティティ オブジェクトを読み込み、DbContext を破棄し、さらに編集するためにこのエンティティ オブジェクトへの参照を保持します。

2. クライアント アプリ 2 は、手順 1 と同じエンティティ オブジェクトを読み込み、プロパティを変更して、変更を保存します。これにより、DB の ROW_VERSION が増加します (現在は 2 です)。

3. クライアント アプリ 1 のユーザーは、エンティティ オブジェクトのいくつかのプロパティを変更します (これは、ROW_VERSION が 1 でメモリ内にあります)。

4. クライアント アプリ 1 は、変更を保存する前に、他のエンティティ オブジェクトを表示用に読み込み、最終的に問題のエンティティ オブジェクトを再度選択します (たとえば、行った変更を確認するため)。これにより、結果に既に変更されたエンティティ オブジェクトが含まれるクエリが発生します (実際のクエリがデータベースに送信される前に DbContext にアタッチされるため)。

   ここに私の問題があります: この時点で、エンティティ フレームワークは、添付されたオブジェクトの ROW_VERSION を実際のクエリ結果のオブジェクトの ROW_VERSION と比較し、不一致を検出して、たとえば例外をスローすることができます。

   ただし、代わりに、EF は ROW_VERSION プロパティを、クライアントによって変更された可能性のある他のすべてのプロパティと同様に扱います。

したがって、EF が ROW_VERSION プロパティを特別に扱い、すべてのクエリでその値を比較して、他のクライアントによる変更を検出することを望みます。このようにして、SaveChanges 呼び出しを待機するよりも早く同時実行状況を検出します。

@VersionJPA と Hibernate を使用した楽観的同時実行制御に使用したいと考えています。

2 つの並列トランザクションの典型的なシナリオでそれがどのように機能するかを知っています。versionまた、フォームとエンティティ間の 1:1 マッピングを持つ CRUD がある場合、非表示フィールドとして渡して、これを使用してユーザーによる同時変更を防ぐことができることも知っています。

DTO を使用したり、コマンド パターンを変更したりする、より興味深いケースについてはどうでしょうか。@Versionこのシナリオでも使用できますか?また、どのように使用できますか?

例を挙げましょう。

ここで、2 人のユーザーがこのために GUI を開き、いくつかの変更を行い、変更を保存するとします (同時にではなく、トランザクションが重複しないようにします)。

エンティティ全体を渡すと、2 番目のトランザクションは失敗します。

それは良いことですが、どこでもエンティティを渡すという考えは好きではなく、DTO や変更コマンドなどを使用することもあります。

簡単にするために、change コマンドはマップであり、最終的に一部のサービスで次のような呼び出しで使用されます。

明らかに、2 人のユーザーが私の GUI を開いた場合、両方が変更を行い、それを次々に実行します。この場合、両方の変更が適用され、最後の変更が「勝ち」ます。このシナリオで同時変更も検出したいと思います (2 番目のユーザーは例外を受け取る必要があります)。

どうすれば達成できますか？

これはこことここで何度も尋ねられましたが、PL/PgSQL関数で更新ステートメントを実行してGET DIAGNOSTICS integer_var = ROW_COUNT.

生のSQLでこれを行う必要があります。

たとえば、MS SQL SERVER には @@ROWCOUNT があり、次のように使用できます。

データベースへの1回の往復で、更新が成功したかどうかがわかり、計算された値が返されます。

'@@ROWCOUNT' の代わりに何を使用できますか? 現時点でこれが実際に不可能であることを誰かが確認できますか?

前もって感謝します。

EDIT 1：生のSQLを使用する必要があることを確認します（元の説明では「生のplpgsql」と書きました）。

私の質問をより明確にするために、update ステートメントは 1 行のみに影響することを考慮し、楽観的同時実行について考えてください。

1. クライアントはSELECT最初に声明を出しました。

2. 彼は UPDATE を構築し、どのデータベースの計算カラムを SELECT 句に含めるかを知っています。特に、述語には、行が更新されるたびに計算されるタイムスタンプが含まれます。

3. したがって、1 行が返された場合は、すべて問題ありません。行が返されない場合は、以前の更新があったことがわかり、クライアントは句を再度更新する前にデータを更新する必要がある可能性があります。これが、計算列を返す前に更新ステートメントの影響を受けた行数を知る必要がある理由です。更新が失敗した場合、行は返されません。

投機的評価 (別名、投機的実行) は、時折の手直し (非効率) を犠牲にして、低レイテンシーのコードを実現するための効果的なアプローチです。投機的評価は、現代のコンピューター アーキテクチャで一般的な低レベルの手法ですが、高レベルのプログラミング モデルでサポートできます (タイム ワープ プロトコル、時相論理、リアクティブ プログラミング モデルを参照)。

投機的評価が特に役立つと思われる場所の 1 つは、ライブ コーディングやゲームなどのオーディオのリアルタイム計算です。アイデアは単純です。オーディオ バッファーを投機的に満たしてバッファー アンダーランを防ぐことができますが、最後の瞬間の変更に対応する必要がある場合は、それらのバッファーを時々修正します。このような手法は、依然として不具合を起こす可能性があります。更新が遅れていると、前面が少し切り落とされる可能性があります。しかし、推測されたサウンドのほとんどはまだほとんど正しいはずなので、これは通常のアンダーランとは異なる (潜在的により優雅な) グリッチのモードです。

さて、私が疑問に思っているのは、どのオーディオ API またはライブラリが、既存のバッファに対するこれらの最後の瞬間の更新を最も効果的にサポートするかということです。私は健全なプログラミングの専門家ではありませんが、私が見たほとんどのサンプル コードは、バッファーへのコミットメントを想定しているようです。バッファを読み込んだ後にバッファにコミットしている場合、レイテンシとアンダーランのリスクとの間でトレードオフを行うしかありません。コミットメントを必要としないオーディオ API はどれですか?

EF DbContext を使用します。私のエンティティ オブジェクトには、同時実行チェック (ConcurrencyMode = Fixed、StoreGeneratedPattern = Computed) に使用される rowversion 列 (SQL Compact エディション バージョン 4) があります。

同時実行例外を強制するために、UI から同じテーブル レコードを 2 つの異なるフォームで読み取り、それぞれを編集して、次々に保存しました。次のコードは、実際の保存操作を行います。

2 番目のフォームの保存ボタンをクリックすると、予期したとおりに同時実行エラーが発生します。ただし、データベースから元の値をコピーした後、2 回目の試行では例外が引き続き発生します。3 回目の試行のみがエラーなしで成功します。誰かがこの問題の原因を説明できますか?

編集:UIを介して両方の更新を行うと発生することがわかりました。上記のコードで、最初の試行の前に、次のことを行います。

myEntity の別のインスタンスが UI を介して更新された場合、コードは期待どおりに機能します。つまり、2 回目の試行で myEntity が保存されます。そして、問題は次の行にあります。

UI を介して更新すると、 exc.Entries は同時実行エラーが発生したエンティティではなく、そのナビゲーション プロパティ エンティティを返すためです。

この場合、MyEntity はツリー状の自己参照エンティティであり、ParentEntity と Children の 2 つのナビゲーション プロパティがあります。

したがって、最初の保存試行の後、exc.Entries にあるのは (変更されていない状態の) ParentEntity であり、2 回目の保存試行の後でのみ、exc.Entries は同時実行エラーがスローされた実際のエンティティを返します。

プロジェクト タスクを含むデータベース テーブルがあります。各タスクは、同じテーブルに格納されているタスク テンプレートに基づいています。タスクは、特に指定されていない限り、関連するタスク テンプレート レコードからプロパティ/フィールドを継承します。このテーブルのデータモデルに自己参照関連付けを作成しました - TaskTemplateId はテンプレートの ID を指します。

私はたくさんの問題を抱えています。テーブル内のデータを変更していない場合でも、更新時に ChangeConflicException が発生します。

理論的に、私はこれを正しい方法で行っていますか? 誰かが以前にこれら2つの問題に直面したことがありますか?

列名 X が結果列リストに複数回表示されます。

プロパティの例を次に示します。

いくつかのメモ:

• このテーブルのすべての非 PK 列で UpdateCheck を never に設定しました。

編集:したがって、LINQ がサーバーに送信している更新ステートメントは次のとおりです。

それは奇妙ではありませんか？どこで 0 = 1? 以下のコードは、サーバーからプロジェクト タスクを取得しています。update ステートメントの後で、このコードを 4 回起動します。

update ステートメントは、UserControl 内の LinqDataSource によって起動されています。カスタム プロパティを除いて、すべてがマークアップで行われます。その例を一番上に示します。

いつもお世話になっております。

(おそらく) 変更されたビュー モデルをサーバーにポスト/セーブ バックするときに楽観的な同時実行性チェックを行うために、ノックアウト バインディングでバインドする監視可能な変数とは別の変数に元の値のコピーを取りたいと考えています。

これはノックアウト マッピング プラグインで行うことができますか、それとも、ビュー モデルにデータを入力した後に、マップされたオブザーバブルを反復処理してコピーを作成する必要がありますか?

VS2012でのデバッグ中にこの例外を受け取りました

同じキーを持つオブジェクトは、ObjectStateManagerにすでに存在します。ObjectStateManagerは、同じキーを持つ複数のオブジェクトを追跡できません。

私は、結果が得られずに、DbFactory、Unit of Work、DI、GenericRepositoryのパターンで楽観的並行性を解決しようとしてほぼ1週間を費やしました。

私はエンティティ フレームワーク 4 を使用しています。フォームには、DataGridViewエンティティのリストが として割り当てられていDataSourceます。次に、2つのボタンがあります。historial_borrarlist( ) の最後の entity( ) を削除するものlista_historial_prestamoで、実際には の最初の行ですDataGridView。

次に、もう 1 つのボタンで、新しいエンティティをデータベースに追加します。

ボタンがクリックされるたびDataSourceにDataGridView( )の を明らかに更新します。dgv_Historial_estado_prestamo

アイデアは、1 つ追加すると、その後でその 1 つを削除できるということです。

そして、1 つ追加してから、それを削除するとします。を取得しOptimisticConcurrencyExceptionます。

なぜだかよくわかりません！オブジェクトをSaveChanges()削除するか、データベースに追加するたびに。リストからも削除しdatasourceます。

オブジェクトを追加した後にオブジェクトを削除すると、この例外が発生します。

私はいくつかの投稿を読んでいて、これを試しました：

このコードに例外はありませんが、そのフォームを閉じて再度開くと、削除したすべてのオブジェクトが実際に存在します。

VS 2012 に同梱されている Framework 4.5 と EF 5.0 を使用しています。同時実行チェックに使用する予定の RowVersion という名前の列を含むエンティティがあります。これは、レコードの INSERT または UPDATE 時に自身を更新する MySQL テーブルの「タイムスタンプ」値​​です。

デフォルトの EF 5 codegen は、次の POCO を生成します。

「RowVersion」プロパティの同時実行モードを「固定」に設定して、同時実行チェックを有効にしました。「StoreGeneratedPattern」は「Computed」に設定されています。オートマッパーを介してマップされた DTO を使用して、WCF サービスを介してデータを送信しています。

サービスを介して返されるエンティティの更新に問題があります。ここにいくつかのコードがあります：

これは、「rowVersion」が変更されていない場合でも、常に OptimisticConcurrencyException をスローすることになります。これは、DTO をエンティティにマッピングし直したことが原因ですか?

誰かが私を正しい方向に向けることができますか?

よろしく