問題タブ [optimistic-concurrency]

ISession.Merge() を使用して 2 つのセッション間の一貫性を維持しようとしましたが、マージされたインスタンスの Version プロパティがセッションで読み込まれたものよりも高い場合 (StaleObjectStateException を使用)、失敗します。

バージョン フィールドが一致しない場合に機能する代替方法はありますか?

hashcode()永続エンティティをオーバーライドするときequals()は、ID を含めず、オブジェクトを一意に識別する意味のあるプロパティのみを含める必要があることを知っています。しかし、Hibernate による楽観的同時実行制御versionに使用されるフィールドはどうでしょうか? IDと同じように、スキップする必要がありますか？とにかくHibernate OCCを混乱させませんか？new User(name='John', version=1).equals(new User(name='John',version=2))

私はc＃とasp.netを使用して自分のWebサイト用のフォーラムシステムを作成しています。データアクセス用には型付きデータセットを使用し、UI用にはmvpパターンを使用しています。私のデータベースには、データセットに追加されたストアドプロシージャがあります。問題は、データセットで[楽観的同時実行性を使用する]チェックボックスを選択できなかったため、自分で楽観的同時実行性を実装する必要があったことです。テーブルにタイムスタンプ列が追加されましたが、ユーザーごとにこの値を保存する際に問題が発生しました。では、タイムスタンプ値を保存するために使用するのに安全でコストのかからない状態管理アプローチはどれですか？

値を格納するためにセッションを使用するのが最善だと思いましたが、ユーザーの数が増えるとメモリリソースに問題が発生しますが、メモリの代わりにSQLサーバーを使用するようにセッションを設定できますが、それがどれほど遅くなるかはわかりませんだから私はそれについて決めることができません。

どんな助けでも大歓迎です！

編集1：はい。行の最後の変更を追跡して、ユーザーが持っているものと一致するかどうかを確認したいと思います。しかし、ユーザーのタイムスタンプ値をどこに保存するかわかりません。

オプティミスティック コンカレンシーをチェックするためにデータ ソースのチェック ボックスをオンにしようとすると、データを編集できなくなります。次のようなエラーが表示されます。

「1 つ以上の必須パラメーターに値が指定されていません。」

sqldatasource1 でこれをバイパスする方法がわかりません。また、新しいレコードを挿入しようとすると、顧客 ID を追加するフィールドがありませんか? 以下は私のコードです。申し訳ありませんが、これはまだ新しいです。

Raven.Server.exe.configで楽観的同時実行性をtrueに設定する方法はありますか？または、データベースレベルで何らかの形で適用できますか？RavenDBのサイトで、UseOptimisticConcurrency = trueの設定についていくつか言及されていますが、コード内のセッションレベルにあるように見えます。

その設定がサーバー全体のどこかに存在するかどうかを知りたいので、コードでセッションごとに指定する必要はありません。

編集：上記のコードは次のエラーを生成します。理由を見つけようとしています...

編集2：わかりました、私は進歩しています。オブジェクトを取得し、すべて同じセッション内でGetEtagFor（）を呼び出すと、有効なeTagが取得されます。ですから、私の主な質問は次のとおりです。クライアントUI内でセッションを使用して、アプリの起動時にセッションを1回開き、最後に閉じる方法は正しいですか。そして...eTagを保存する正しい方法は何ですか？上でコーディングした方法では、eTagは保存する直前に取得されますが、これは間違った方法だと思います。オブジェクトが最初に取得されたときにeTagを取得する必要があると思います。しかし、最初にオブジェクトのリストを取得するとき、それぞれをループして、それらに対してGetEtagFor（）を呼び出す必要がありますか？正しくないようです...

RavenDBを使用するとIDocumentSession、アプリの起動時に作成し（アプリが閉じられるまで閉じない）、次のようにして楽観的同時実行性を使用できます。

別のユーザーがそのオブジェクトを変更した場合、保存は正しく失敗します。

しかし、アプリの存続期間中に1つのセッションを使用する場合、私ができないことは、アプリの他のインスタンス（たとえば、5キュービクル離れたジョー）によってドキュメントに加えられた変更を確認することです。これを行うと、ジョーの変更が表示されません。

注：これも試しましたが、Joeの変更も表示されませんでした。

さて、IDocumentSession逆に、データベースにアクセスするすべてのメソッド内に作成すると、逆の問題が発生します。新しいセッションがあるので、ジョーの変化を見ることができます。Buuuuuuut...それから私は楽観的同時実行性を失います。保存する前に新しいセッションを作成すると、この行は空のGUIDを生成するため、失敗します。

私は何が欠けていますか？各メソッド内でもアプリレベルでもセッションを作成するべきではない場合、正しいスコープは何ですか？Session.Query（）を実行するときに、楽観的同時実行性と他のユーザーの変更を確認する機能の利点をどのように得ることができますか？

相互運用性のために設計されたオプティミスティック ロック/オプティミスティック同時実行制御(OCC)用の Web サービス標準 (WS*) はありますか?

WS-AtomicTransactionなど、悲観的同時実行制御メカニズムに関連する標準は多数ありますが、私が知る限り、楽観的ロックに関連するバージョンまたはタイムスタンプ処理の機能は提供されていません。

楽観的ロックと WCFに関する記事を 1 つ見つけましたが、市長の標準はありません。そのようなものはありますか、または他のサンプルやパターンをお勧めしますか?

バックグラウンド

（SOAP）WebサービスがありBookService、図書館の本を管理していると仮定します。Book情報モデルでは、エンティティに次の属性があると想定しています。

• id
• author
• publisher
• title
• shelfId

データを操作するために、4つのWebサービス操作が定義されています。

• AddBook
• GetBook
• UpdateBook
• DeleteBook

要求メッセージと応答メッセージは、操作ごとに定義されています。ただし、更新メッセージXMLスキーマの設計はより複雑です。私たちは以下の資質を達成したいと考えています。

• R1：属性の以前の値をリセット/削除する可能性。たとえば、本をライブラリに保持しなくなったshelfIdため、その特定の本の属性の属性値をリセット/空にする/削除したいとします。
• R2：Webサービスでのおしゃべりを避けてください。アンチパターンのChattyServicesを参照してください。
• R3：同時実行制御とオプティミスティックロックに関する将来の要件に備えます。古い情報に基づいて更新が行われるリスクを最小限に抑える（または削除する）ことができます。

代替案の設計

更新メッセージを設計するための3つの市長の選択肢があり、そのうちの1つにはいくつかのサブオプションがあります。

1. ビジネスドキュメント全体を送信します。省略された要素（minOccurs="0"スキーマ内にある）または明示的にnullに設定された要素、つまり<shelfId xsi:nil="true"/>、は、前の値の削除として解釈されます。
2. 変更を強調表示するか、差分のみを送信します。
   1. ビジネスドキュメント全体を送信しますが、この目的に固有の属性を使用して、変更された要素にマークを付けます。例：<author dirty="true">Hemingway<author/>。次に、サービスのプロバイダーは、ダーティとしてマークされた要素のみを更新し、他の要素を無視します。
   2. メッセージスキーマで、識別子を除くすべての要素をに設定しidますminOccurs="0"。コンシューマーは、変更される要素のみを送信します。省略された要素は、意味的に削除として解釈されてはなりません。値を削除するには、明示的なXMLNULL値を使用する必要があります。例：<shelfId xsi:nil="true"/>。
   3. ビジネスドキュメント全体を送信するだけでなく、以前に読んだドキュメントのコピーも送信します。次に、プロバイダーは2つのドキュメントを比較し、新しいドキュメントと以前のドキュメントが異なる属性のみを更新できます。
3. 複数の操作を定義します。1つの操作だけを使用するのではなく、更新UpdateBookする必要があると思われる要素に基づいて複数の操作を定義します。これらのそれぞれには必須の要素のみがあり、要素を削除するには、XMLの明示的なNULLを使用します。UpdateBookAuthorUpdateBookPublisher<shelfId xsi:nil="true"/>

討論

Alt 3Bookには、理解しやすいという利点がありますが、エンティティ内の複数のフィールドを更新する必要がある場合に、コンシューマーが複数の操作を呼び出す必要があるという欠点があります。これにより、サービスが「おしゃべり」になり（上記のR3を参照）、パフォーマンスが低下します。

Alt2はAlt1よりも複雑ですが、楽観的同時実行制御に関連するAlt2にはいくつかの利点があります。

• 各フィールドのタイムスタンプ/バージョンを使用した楽観的ロックがデータベースに保存されている場合（例authorVersion）=> Alt 2は、複数のユーザーが同じのとなどの異なる部分を同時に変更できるようにするとauthor同時に、障害が発生するリスクを減らす方法を提供します。publisherBook
• 全体に対して単一のタイムスタンプ/バージョンを使用した楽観的ロックがBookデータベースに保存されている状況の場合=> Alt1に対するAlt2の実際の利点はありません。更新によって1つのフィールドのみが変更された場合でも、リクエストのバージョン番号が古すぎると障害が発生します。
• 同時実行制御または楽観的/悲観的ロックが使用されていない状況の場合=> Alt2は、 Alt 1よりも古いデータで上書きするリスクが少なくなりますが、他の一貫性のない変更によって問題が発生する可能性があります。

Alt 2（およびAlt 3）がAlt1よりも有利であるさらに別の状況があります。消費者は、エンティティに関するすべてのデータを保存できない場合があります。たとえば、棚の情報を更新するときに、著者の情報を追跡（キャッシュ）する必要がなく、棚だけを追跡する必要がある場合、棚から本を選ぶロボットをより効果的にプログラムできます。Book

コンシューマーがバージョン番号やタイムスタンプの代わりに以前のバージョンのコピー全体を送信するAlt2.3のアプローチの利点は、バージョン番号やタイムスタンプにデータベース内の専用の列が必要ないことです。

要約すると、 Alt2.2はほとんどの場合最も魅力的なもののように見えます。ここでの課題は、XMLを逆シリアル化するフレームワークが、除外された要素と明示的にNULLに設定された要素を区別できなければならないこと<shelfId xsi:nil="true"/>です。このトピックに関する投稿はこちらをご覧ください。

質問

どちらの選択肢を選びますか？他のより良い選択肢がありますか？議論についてどう思いますか？

ConcurrentDictionaryで、指定した値と等しい場合にのみ、キーでエントリを削除できるメソッドを探していました。これは、 TryUpdateと同等ですが、削除するためのものです。

これを行う唯一の方法は、次の方法のようです。

これはICollectionインターフェイスの明示的な実装です。つまり、Removeを呼び出すことができるように、最初にConcurrentDictionaryをICollectionにキャストする必要があります。

Removeは私が望むことを正確に実行し、そのキャストも大したことではありません。また、ソースコードは、bool matchValue =trueを指定してプライベートメソッドTryRemovalInternalを呼び出すことを示しているため、すべてがきれいに見えます。

ただし、少し心配なのは、ConcurrentDictionaryの楽観的に並行するRemoveメソッドとして文書化されていないため、http：//msdn.microsoft.com/en-us/library/dd287153.aspxはICollectionボイラープレートを複製するだけです。方法：ConcurrentDictionaryからアイテムを追加および削除する方法についても、その方法については触れられていません。

それが進むべき道かどうか誰かが知っていますか、それとも私が見逃している他の方法がありますか？