マルチスレッドサービスでのデータベース接続プーリング

Question

私は、スレッド化にTPLライブラリを使用している.NET 4 C＃サービスを持っています。 1つの接続が処理用のボトルネックになっていたため、最近は接続プーリングも使用するように切り替えました。

以前は、接続オブジェクトのスレッドの安全性を制御するためにlock句を使用していました。作業がバックアップされると、キューはタスクとして存在し、多くのスレッド（タスク）がロック句を待機します。現在、ほとんどのシナリオでは、スレッドはデータベースIO上で待機し、プロセスを非常に高速に処理します。

ただし、接続プールを使用しているので、新しい問題があります。接続の最大数に達すると（デフォルトは100）、さらに接続が要求されるとタイムアウトが発生します（Pooling info参照）。この場合、「接続要求がタイムアウトしました」という例外がスローされます。

私のすべてのIDisposablesはステートメントを使用しています。私は接続を正しく管理しています。このシナリオは、プールが処理できる（期待されている）よりも多くの作業が要求されているために発生します。私はこの例外がなぜスローされるのか理解し、それを処理する方法を認識しています。単純なリトライはハックのように感じます。また、接続文字列を使用してタイムアウト時間を増やすこともできますが、これは固いソリューションのようには感じられません。以前の設計（プーリングなし）では、アプリケーション内のロックのために作業項目が処理されていました。

このシナリオを処理してすべての作業が確実に処理されるようにするにはどうすればよいでしょうか？あなたは次のようにParallel.ForEach()方法を使用して並列度を制御するために見ることができる

Answer 1

もう1つの方法は、プールから接続を取得するコードの周りにsemaphoreを使用することです（うまくいけば返す）。 sempahoreはlockステートメントと似ていますが、1つだけでなく、同時に複数のリクエスタを設定できる点が異なります。

このような何かを行う必要があります

：

//Assuming mySemaphore is a semaphore instance, e.g. 
// public static Semaphore mySemaphore = new Semaphore(100,100); 
try { 
    mySemaphore.WaitOne(); // This will block until a slot is available. 
    DosomeDatabaseLogic(); 
} finally { 
    mySemaphore.Release(); 
} 

Answer 2

：この場合

var items = ; // your collection of work items 
var parallelOptions = new ParallelOptions { MaxDegreeOfParallelism = 100 }; 
Parallel.ForEach(items, parallelOptions, ProcessItem) 

を私は100に度を設定することを選んだが、あなたはのために理にかなって値を選択することができます現在の接続プールの実装。

この解決方法は、作業項目のコレクションが前面にあることを前提としています。ただし、着信Webリクエストなどの外部メカニズムを使用して新しいタスクを作成している場合、例外は実際には良いことです。この時点では、作業項目を配置してワーカー・スレッドが使用可能になったときにそれらをポップすることができる同時キュー・データ構造を使用することをお勧めします。

Answer 3

最も簡単な解決策は、失敗を返す前にリクエストをブロックしたい時間の長さに接続タイムアウトを増やすことです。 「あまりにも長い」時間があるはずです。

これは、タイムアウトのある作業キューとして接続プールを効果的に使用します。自分で実装しようとするよりもはるかに簡単です。接続プールが公平（FIFO）であることを確認する必要があります。