JDBC 接続を閉じていない場合は、これが正しい動作です。
各 JDBC リソースとそれで取得した他の JDBC リソースの使用が終了したら、各 JDBC リソースの close() メソッドを呼び出す必要があります。
これは、Connection、Statement/PreparedStatement/CallableStatement、ResultSet などに当てはまります。
これを怠ると、まず第一に、SQL サーバー上に潜在的に巨大でおそらく非常に限られたリソースを蓄えることになります。
最終的に、接続は許可されず、get クエリを実行して結果を返すことが失敗するかハングします。
また、autoCommit プロパティを true に設定していない場合、各トランザクションの終了時に commit() または rollback() に失敗すると、INSERT/UPDATE/DELETE ステートメントがハングすることに気付く場合があります。
私が見たのは、上記の厳密さを JDBC クライアント コードに適用すると、JDBC と SQL サーバーが驚くほどスムーズに動作するということです。がらくたを書くと、すべてががらくたのように動作します。
多くの人が JDBC 呼び出しを作成し、close() を呼び出すことによって「何か」が他のものを解放することを期待しています。
それは本当ですが、それらのプログラマーは、サーバーで「壁に 99 本のビール」を再生するプログラムを作成しました。
リソースが使い果たされ、要求は次の 1 つまたは複数の事象を引き起こす傾向があります: 接続要求がすぐに失敗する、SQL ステートメントがすぐに失敗する、または永久にハングする、または非常に長いトランザクション タイムアウト タイマーが期限切れになるまで、など。
したがって、これらのタイプの SQL の問題を解決する最も簡単な方法は、SQL サーバー、アプリケーション サーバー、Web コンテナー、JDBC ドライバー、または Java ガベージ コレクターに埋め込まれた人工知能の残念な欠如を責めないことです。
それらを解決する最も簡単な方法は、アプリケーションで SQL サーバーと通信する JDBC 呼び出しを作成した人物をナーフ ダーツで撃つことです。彼が「何のためにそれをしたのですか...?!」と言ったとき。この投稿を指して、読むように伝えてください。(目、手に持っているもの、危険/壊れやすいものなどを狙って撃たないように注意してください。)
あなたの問題を解決する接続プーリングに関しては...いいえ。申し訳ありませんが、接続プールは、事前に割り当てられた、おそらく再利用された接続をアプリケーションに渡すことで、アプリケーションで接続を取得するための呼び出しを高速化するだけです。
歯の妖精は枕の下にお金を置き、イースターバニーは茂みの下に卵とキャンディーを置き、サンタクロースはツリーの下にプレゼントを置きます。しかし、あなたの幻想を打ち砕いて申し訳ありません - 自分で割り当てたものをすべて閉じるのを「忘れた」ため、SQL サーバーと JDBC ドライバーはすべてを閉じるわけではありません。