|
接続プールを使用すれば、作成済みの接続を再利用できるので、データ プロバイダーはデータベースに接続するたびに新しい接続を作成する必要がなくなります。データ プロバイダーでは .NET クライアント アプリケーションで自動的に接続プールを使用できるようになりました。
接続プールの動作は、接続文字列オプションによって制御することができます。たとえば、接続プール数、プール内の接続数、接続が破棄されるまでの時間(秒数)を定義することができます。
ADO.NET の接続プールは .NET Framework によって提供されません。ADO.NET データ プロバイダー自体に実装する必要があります。
各接続プールは、それぞれ特有の接続文字列と関連付けられます。デフォルトでは、接続プールは一意な接続文字列を使って最初にデータベースに接続したときに作成されます。プールには、プールの最小限のサイズまで接続が格納されます。プールが最大限のサイズに達するまで、接続がプールに追加されていきます。
プールは、その中で接続が開いている限り、あるいは、Connection オブジェクトへの参照を持つアプリケーションによって使用されており、そのオブジェクトに開いている接続がある限り、アクティブであり続けます。
新しい接続を開いたとき、その接続文字列が既存のプールと一致しない場合は、新しいプールを作成する必要があります。同じ接続文字列を使用することで、アプリケーションのパフォーマンスやスケーラビリティを向上させることができます。
以下の C# コード例では、3 つの新しい PsqlConnection オブジェクトが作成されます。ただし、これらのオブジェクトを管理するために必要な接続プールは 2 つのみです。1 番目と 2 番目の接続文字列では、ユーザー ID とパスワードに割り当てられる値だけが異なることに注意してください。
DbProviderFactory Factory = DbProviderFactories.GetFactory("Pervasive.Data.SqlClient");
DbConnection conn1 = Factory.CreateConnection();
conn1.ConnectionString = "Server DSN=DEMODATA;User ID=test;Password=test;Host=localhost;"
conn1.Open();
// プール A が作成されます。
DbConnection conn2 = Factory.CreateConnection();
conn2.ConnectionString = "Server DSN=DEMODATA2;User ID=lucy;Password=quake;Host=localhost;"
conn2.Open();
// 接続文字列が異なるため、プール B が作成されます
DbConnection conn3 = Factory.CreateConnection();
conn3.ConnectionString = "Server DSN=DEMODATA;User ID=test;Password=test;Host=localhost;"
conn3.Open();
// conn3 は conn1 と一緒にプール A に入ります。
接続プールは、アプリケーションが使用する一意な接続文字列を作成している最中に作成されます。プールが作成されると、Min Pool Size 接続文字列オプションによって設定される、プールの必要最小限のサイズ条件を満たすだけの接続がプールに格納されます。アプリケーションが Min Pool Size を超える接続を使用する場合、データ プロバイダーは Max Pool Size 接続文字列オプション(プール内の最大接続数を設定します)の値になるまで、プールに接続を追加割り当てします。
Connection.Open(...) メソッドを呼び出すアプリケーションで Connection オブジェクトが要求されたとき、プールから使用可能な接続が入手できる場合には、接続はプールから取得されます。使用可能な接続とは、現在ほかの有効な Connection オブジェクトによって使用されておらず、合致する分散トランザクション コンテキストを持ち(妥当な場合)、サーバーへの有効なリンクを持っている接続と定義付けられます。
プールの最大サイズに達し、かつ入手できる使用可能な接続がない場合には、要求はデータ プロバイダーのキューに入れられます。データ プロバイダーは使用可能な接続をアプリケーションへ返すために、Connection Timeout 接続文字列オプションの値が示す時間だけ待ちます。この時間が経過しても接続が入手可能にならなかった場合は、データ プロバイダーはアプリケーションにエラーを返します。
データ プロバイダーに対し、プールされている接続数に影響を与えないで、指定したプールの最大サイズを超える接続を作成できるようにすることができます。これはたとえば、時折発生する接続要求の急増を処理する場合などに有用です。Max Pool Size Behavior 接続文字列オプションを SoftCap に設定することにより、作成される接続数は Max Pool Size に設定された値を超えることが可能になりますが、プールされる接続数は設定値を超えません。プールの最大接続数が使用されている場合、データ プロバイダーは新しい接続を作成します。接続がプールに返されたとき、そのプールにアイドル状態の接続が入っている場合には、プール メカニズムは接続プールが Max Pool Size を決して超えないよう、破棄する接続を選択します。Max Pool Size Behavior を HardCap に設定した場合、作成される接続数は Max Pool Size に設定された値を超えません。
重要:PsqlConnection オブジェクトの Close() または Dispose() メソッドを使用して接続を閉じると、その接続はプールに追加されるか戻されます。アプリケーションで Close() メソッドを使用した場合、接続文字列の設定は Open() メソッドを呼び出す前の状態にとどまります。Dispose メソッドを使用して接続を閉じた場合には、接続文字列の設定は消去され、デフォルトの設定に戻されます。
接続プールから接続が削除されるのは、Load Balance Timeout 接続文字列オプションで決められた存続時間が過ぎた場合や、接続文字列の一致する新しい接続がアプリケーションによって開始された(PsqlConnection.Open() が呼び出された)場合です。
接続プールの接続をアプリケーションに返す前に、プール マネージャーはその接続がサーバー側で閉じられているかどうかを確認します。接続が有効でなくなっていれば、プール マネージャーはその接続を破棄し、プールから別の入手可能で有効な接続を返します。
再使用するための接続プールから接続をどのような順序で削除するかを、Connection Pool Behavior 接続文字列オプションを用いて、接続の使用頻度または使用時期を基に制御することができます。接続をバランスよく使用するには、LeastFrequentlyUsed 値または LeastRecentlyUsed 値を使用します。あるいは、毎回同じ接続を使用した方がパフォーマンスが良くなるアプリケーションの場合は、MostFrequentlyUsed 値または MostRecentlyUsed 値を使用できます。
Connection オブジェクトの ClearPool メソッドおよび ClearAllPools メソッドは、接続プールからすべての接続を削除します。ClearPool は特定の接続に関連付けられている接続プールを空にします。対照的に、ClearAllPools はデータ プロバイダーによって使用されるすべての接続プールを空にします。メソッドを呼び出すときに使用中だった接続は、閉じるときに破棄されます。
メモ:デフォルトで、無効な接続を破棄することによって、接続数が Min Pool Size 属性で指定した数より少なくなった場合、新しい接続はアプリケーションで必要になるまで作成されません。
アイドル状態の接続が、そのデータベースへの物理的接続を失った場合には何が起こるのでしょうか。たとえば、データベース サーバーが再起動されたり、ネットワークが一時的に中断されるとします。プール内の既存の Connection オブジェクトを使って接続しようとするアプリケーションは、データベースへの物理的接続が失われているため、エラーを受け取る可能性があります。
Pervasive PSQL ADO.NET データ プロバイダーはこの状況をユーザーに意識させないで処理します。Connection.Open() では、データ プロバイダーは単に接続プールから接続を返すだけなので、アプリケーションはこのとき何のエラーも受け取りません。SQL ステートメントを実行するために Connection オブジェクトが初めて使用されたとき(たとえば、Command オブジェクトの Execute メソッドを介して)、データ プロバイダーはサーバーへの物理的接続が失われていることを検出し、SQL ステートメントを実行する前にサーバーへの再接続を試みます。データ プロバイダーがサーバーへ再接続できた場合、アプリケーションには SQL の実行結果が返され、エラーは何も返されません。データ プロバイダーはこのシームレスな再接続を試みる際、接続フェイルオーバー オプションが有効になっていればそれを利用します。プライマリ サーバーが使用できないときはバックアップ サーバーへ接続するようデータ プロバイダーを構成する方法については、接続フェイルオーバーの使用を参照してください。
メモ:データ プロバイダーは、SQL ステートメントの実行時にデータベース サーバーへの再接続を試みることができるため、ステートメントが実行されるときに接続エラーをアプリケーションへ返すことができます。データ プロバイダーがサーバーに再接続できない(たとえば、サーバーがまだダウンしている)場合、実行メソッドは再接続の試行が失敗したことと、その接続が失敗した理由の詳細を知らせるエラーをスローします。
この接続プール内の停止接続を処理する技術には、接続プール メカニズムを超越して最高のパフォーマンスを得られるという効果があります。一部のデータ プロバイダーは、接続がアイドル状態である間、ダミーの SQL ステートメントを使って定期的にサーバーに ping を実行します。その他のデータ プロバイダーは、アプリケーションから接続プール内の接続の使用を要求されたときにサーバーに ping を実行します。これらの手法はいずれもデータベース サーバーへの往復を追加するため、結局のところ、アプリケーションの通常の操作が発生している間ずっと、アプリケーションの速度が落ちます。
データ プロバイダーは、このデータ プロバイダーを使用するアプリケーションの調整およびデバッグが行える PerfMon カウンターのセットをインストールします。PerfMon カウンターの詳細については、PerfMon のサポートを参照してください。
|