SqlExceptionsにヒットしたときに再試行するC＃コードがいくつかあります。コードはバニラWebサーバーで実行されており、Sql2k8データベース、標準のものと通信しています。
コードを Azure Web ロールに移植し、データベースを SQL Azure に移行することに関心があります。「接続障害」をキャッチしているように見えるいくつかの EntLib のものを発見しましたが、エンタープライズ ライブラリ コードが自分のビットに対して何を提供しているのかわかりません.... SqlExceptions は SqlExceptions ですよね?
グリゴリの答えに加えて、いくつか追加したいと思います。
一時的な障害処理アプリケーション ブロックには、接続の再試行を保証する (SQL Server データベースではなく) SQL データベースのみがスローする SqlExceptions をカバーするのに役立つ、SQL Azure の既定の再試行ポリシーがあります。重要な理由は、再試行が必要な SqlExceptions に対してのみ接続の再試行を実行する必要があるためです。これは、アプリケーション ブロックを使用する利点の 1 つです。
ただし...アプリケーション ブロックは非常に役立ちますが、SqlExceptions は、クラウドで発生するエラーの 1 種類にすぎません。それは、SQL データベースによって生成されるエラーです。ロード バランサーまたはユーザーと SQL データベースの間にある他の中間プロキシ レイヤーの結果である特定の IO 例外など、接続の再試行を保証する完全性のためにキャッチする必要がある可能性がある (予定の) 他の種類のエラーがあります。この情報に関する信頼できる情報源はありません。単なる個人的な経験。ただし、良いニュースは、アプリケーション ブロックをカスタマイズして、再試行ポリシーで処理する例外の種類を含める方法があることです (または、元の再試行フレームワークには方法があったと言えます)。私は最新バージョンを使用していないので、状況が変わった場合に備えて、この主張をしてください.
したがって、アプリケーション ブロックは、接続している SQL データベース エンジンに関係なく、接続の再試行ポリシーを柔軟に管理し、実際に再試行する例外のリストを適切に制御する方法を提供します。非常に集中化された接続ロジックを持ち、SQL データベースのみを扱うアプリケーションにとってはやり過ぎかもしれませんが、非常に強力なフレームワークです。
エンタープライズライブラリ統合パックforWindowsAzureの一部として出荷された一時的な障害処理アプリケーションブロックを参照しているようです。これには、SQL Azureだけでなく、Windows Azureストレージ、キャッシング、サービスバスの検出戦略に加えて、拡張可能な一連の再試行戦略が含まれています。アイデアは、使用される複数のテクノロジー間で一貫した再試行動作を実現することです。
もちろん、気になるのがSqlExceptionsだけであれば、独自の検出コードを使用できます。