モバイルデバイスから重複した注文をチェックするSQL Serverにストアドプロシージャがあります。サーバーから応答がない場合、デバイスは約1/2秒以内に再試行します。すでに挿入されているにもかかわらず、複製が読み取られないことがあります。 SQL Serverが挿入されたデータをコミットするのに1/2秒遅れることは可能ですか？解決策は、ダーティリードの使用を開始するのですか？挿入されたデータをコミットする際のSQL Serverの遅延
race conditionになっているようです。
すなわち
Time SP Call 1 SP Call 2
0.00 Dup Exists?
0.10 ... Dup Exists?
0.20 No No
0.30 Insert New ...
0.40 Insert New
重複するための手順のチェックを持っているのではなく、あなたが重複を防ぐために、データに一意のインデックスを置くことができますか？
私の意見では、ダーティリードを使用することは決して決してありません。一意性は、制約を介して、場合によってはトリガーの前（または代わりに）で実装する必要があります。どのようなプロシージャについての詳細がなければ、私はより具体的な助言を与えることはできませんが、ストアドプロシージャ本体のトランザクションに直列化可能な分離レベルを使用することで問題が解決できると考えています。また、更新の問題が発生しないように、rowversion列の使用を検討することもできます。
a1ex07と@webturner、あなたの返信ありがとうございます。一意の制約を使用することの難しさは、注文を処理する別のシステムに要求を送信する前に、潜在的な二重引用符をチェックしていることです。したがって、レコードの一意性は目標ではありません。目標は、既に送信され、確認されている場合、他のシステムに注文を提出しないことです。したがって、私はプログラム的な決定を下すために今受け取ったものを複製する行が存在するかどうかを知る必要があります。そういうわけで私はこの特別なケースでは未読のことを考えていたのです。それがより明確になることを願っています。 – user1102311
@webturnerが示唆しているように、これは競合状態であることが判明しました。 SQL Serverで同じデータにアクセスしていたWCFスレッド間でした。貴重な情報もa1ex07にもありがとう。 – user1102311
SQLサーバーが挿入をブロックしている可能性があるサーバー上で起こっている他の作業のために、半分の遅延が発生することは確かです。 – HLGEM