問題タブ [connection-pooling]

.NETのSqlConnectionクラスを使用してSQLServerデータベースと通信するクライアントコードがいくつかあります。このエラーで断続的に失敗しています：

「ExecuteReaderには、開いていて利用可能な接続が必要です。接続の現在の状態は閉じています。」

「一時的な」解決策は、プロセスを再起動することです。その後、すべてが機能しますが、それは明らかに不十分です。

コードは、データベースごとに1つずつ、SqlConnectionインスタンスのキャッシュを保持しています。

コードを書き直したいのですが、その前に、いくつかのことを知っておく必要があります。

私の最初の質問は次のとおりです。SqlConnectionオブジェクトを繰り返し接続および切断するのは非効率的ですか、それとも基盤となるライブラリが私たちに代わって接続プールを実行しますか？

私たちのコードは上記を行わないため、問題の原因として考えられるのは、接続の「存続期間」中に基盤となるSQLServerデータベースに何かが発生し、接続が閉じられることです。

SqlConnectionオブジェクトを「キャッシュ」する価値があることが判明した場合、データベースに「再接続」するだけで解決できるすべてのエラーを処理するための推奨される方法は何ですか。私は次のようなシナリオについて話している：

• データベースがオフラインになり、オンラインに戻りますが、これが発生している間、クライアントプロセスには開いているトランザクションがありませんでした
• データベースは「切断」され、次に「再接続」されました

SqlConnectionに「State」プロパティがあることに気付きました...それを照会する適切な方法はありますか？

最後に、完全なアクセス権でセットアップされたテストSQLServerインスタンスがあります。「ExecuteReaderには開いた使用可能な接続が必要です。接続の現在の状態は閉じています」という正確なエラーを再現するにはどうすればよいですか。

具体的には、接続をプールに戻すときに、dbcp (およびその他の接続プール) はステートメントと結果セットを閉じますか?

または、これらを自分で閉じる必要がありますか？

OracleConnectionCacheImplを介したOracle接続プーリングで問題が発生しています。シンドライバを介してデータベースサーバー（Oracle 10g）の接続プールに接続すると、不特定の時間が経過すると、db接続が切断され（おそらくアイドル接続が原因ですか？）、エラーメッセージが表示されるまですべて正常に動作します。

閉じた接続。

ページを更新して接続を再試行するとデータベースが再接続されるため、ネットワークやデータベースに問題はないようです。Oracle接続プールが接続を検証し、プール内の接続が何らかの理由で切断された場合に再接続する方法はありますか？

Apache Tomcat 6.0.18、Java EE6update11を使用しています。

（Oracleシンドライバにはping関数があるようです。それは役に立ちますか？どこで見つけることができますか？）

Tomcat コンテナで Apache DBCP と JNDI を使用して、mysql データベースへの接続をプールしています。すべて正常に動作しますが、pconnection がプールされると解放されないという問題が発生します。そのため、接続の負荷が急上昇した後は、永遠に眠ってしまいます。context.xml パラメータを使用してプールを縮小する方法はありますか? ここに私の構成があります：

私は.NET SqlClient Data Providerを使用してSQLサーバーに接続するクライアントサーバーアプリを持っています - かなり標準的なものです。デフォルトでは、接続プーリング マネージャがデータベース接続を閉じてプールから削除する前に、接続をアイドル状態にしておく必要があるのはどれくらいですか? これを制御する場合、どの設定ですか?

このMSDNドキュメントは、

接続プーラーは、接続が長時間アイドル状態になった後、またはサーバーとの接続が切断されたことをプーラーが検出した場合に、接続をプールから削除します。

私はHaskellを学ぶJavaプログラマーです。
私はHappstackを使用し、HDBCを介してデータベースと通信する小さなWebアプリで作業しています。

select関数とexec関数を作成し、次のように使用します。

ご覧のとおり、非常にシンプルです。クエリ、パラメータ、結果があります。
接続の作成とコミット/ロールバックはselectとexecの中に隠されています。
これは良いことです。「ロジック」コードでは気にしたくありません。

悪い点：

• 呼び出しごとに常に新しい接続が作成されます-これにより、高負荷でのパフォーマンスが低下します
• DBURL「users.db」はハードコードされています-編集せずに他のプロジェクトでこれらの関数を再利用することはできません

質問1：定義された（最小、最大）数の同時接続で接続のプールを導入して、接続がselect / exec呼び出し間で再利用されるようにするにはどうすればよいですか？

質問2：「users.db」文字列を構成可能にする方法は？（クライアントコードに移動する方法は？）

これは透過的な機能である必要があります。ユーザーコードは、明示的な接続処理/解放を必要としないはずです。

（すべての接続にわたって）PreparedSteatementプーリングに関連する質問があります。これが設定ファイルです

この行のようです：

プリペアドステートメントに問題は発生しませんが、次のようになります。

過去20分間トラフィックがなかった場合、すべての接続が削除されて再作成されます。そのため、既存のプリペアドステートメントはキャッシュされたプリペアドステートメントのプールから削除されます。この問題を克服する方法は？MySQLサーバーは8時間後に接続を閉じるため、idle-timeout-minutesを使用する必要があります

SqlConnection オブジェクトをインスタンス化すると、実際には接続プールから接続を取得していることを理解しています。Open() を呼び出すと、接続が開かれます。その SqlConnection オブジェクトで Close() または Dispose() メソッドを呼び出すと、接続プールに返されます。

ただし、それが本当に閉じているかどうか、またはデータベースへのアクティブな接続がまだあるかどうかはわかりません。

SqlConnection をネットワーク レベルで強制的に閉じるにはどうすればよいですか、または少なくともいつ閉じるかを伝えるにはどうすればよいですか?

例：

• 最初の実行: 300 ミリ秒
• 2 回目の実行: 100 ミリ秒
• 3 回目の実行: 100 ミリ秒
• 長時間（30分）待った後：300ミリ秒

接続が本当に閉じていた場合、2 回目と 3 回目の実行も 300 ミリ秒になるはずです。しかし、これらの実行では接続が完全に閉じられていないことがわかっています (SQL Server のアクティビティ モニターを確認しました)。認証などを実行するのに余分な 200 ミリ秒はかかりません。

接続を強制的に閉じるにはどうすればよいですか?

アイデア

• CommandBehavior.CloseConnection は機能しますか? （どうやらそうではない？）
• 接続文字列で「最大プール サイズ = 0」を設定しても機能しますか? （これはピュロス溶液になります）
• Dispose() は機能しますか?

参考文献

• 接続プーリングに関する記事
• Close() が実際には接続を閉じないことを示す別の例を次に示します。
• 接続プーリングの長所と短所に関する記事

Webpshere ApplicationServer6.1内でWebアプリケーションを実行しています。このWebアプリケーションには、ルールの種類のエンジンがあり、すべてのルールがWebsphereデータソースプールから独自の接続を取得します。したがって、ユースケースを実行すると、100レコードの入力に対して、約400〜800の接続がプールから取得され、プールに解放されることがわかります。このエンジンが生産に入ると、処理が完了するまでに時間がかかりすぎるのではないかと感じています。

プールから頻繁に接続を取得するのは悪い習慣ですか？プールから接続を取得するために必要なオーバーヘッドコストはどれくらいですか？私の推測では、プールはリソースキャッシュにすぎないため、関連するコストは最小限に抑える必要があります。私が間違っている場合は訂正してください。

ASP.NET アプリケーションに接続プールのメモリ リークの問題があるとします (たとえば、接続が正しく閉じられていない場合)。

アプリケーション プールをリサイクルすると、接続プールがクリアされますか (したがって、より多くの接続を確立できますか)?

ガベージ コレクターが接続を削除するまで接続がメモリに残っている場合、アプリケーション プールが再起動されたときに発生しますか (または、それを超えて接続を維持できますか)? また、ガベージ コレクターがいつでもそれらをクリーンアップできることも理解していますが、それらはまだ使用されており、リセットまたはアプリケーション プールの再起動まで収集できませんか?

接続を正しく管理するためにコードを修正することが最終目標であることは明らかなシステムをレビューしており、ガベージ コレクション/アプリケーション プール プロセスについて理解を深めようとしています。