今日、アプリケーションでいくつかのエラーが発生し、テーブルにレコードを挿入しようとしたときに、ネットワークの一時的な遅延が原因でタイムアウト エラーが発生したことに気付きました。アプリケーションは、これを認識し、そのような場合に再試行するようにコード化されています。しかし、再試行時に主キー違反が発生しました。基本的には、最初の挿入ステートメントが実際に完了したが、応答をクライアントに送信するときにタイムアウトが発生したためです。主キー違反は、アプリケーションによって、発生してはならない重大な論理エラーであると見なされたため、プロセス全体が中止されました。
私への質問は、この種の処理を論理的にどの層が担当するべきかということです。理想的には、SQL クライアント ライブラリ (この場合は ADO.NET 4.0) がそうするべきだと考えていましたが、私が知っている自動再試行のメカニズムはありません。そうでない場合、SQLクライアントライブラリの低レベルのラッパーができるケースがあるようですが、タイムアウトがいつ発生したかに関する情報へのアクセスがなければ、それをどのように書くことができるかわかりません。一種の例である可能性があります
a) INSERT ステートメントは単純に自動インクリメント キーを使用して新しいレコードを挿入しているため、タイムアウト後に再試行すると重複レコードが挿入される、または b) 主キー違反は実際には論理エラーであり、最初の挿入試行タイムアウトが発生していなければ、aa レコードは同じ違反を生成していたでしょう。
OTOH 再試行するかどうかをアプリケーション レベルでのみ決定できる例を考えられると思います (特に、ユーザーの確認が必要な場合)。
実際にはかなりありそうに見えるので、これまで特に一連のエラーを見たことがなかったので、実際には少し驚いています。