Tomcat サーバーで動作するサーブレットがいくつかあります。今では、リクエストごとにデータベース接続を作成し、使用後にそれらを閉じます。これにより、接続の確立/クローズに大きなオーバーヘッドが発生する可能性があります。単一の接続マネージャー サーブレットを使用して、すべてのサーブレット間でグローバル接続を共有する (つまり、すべてのサーブレットが同じ接続を使用する) とはどうでしょうか。これは良い方法ですか、それとも同時操作に問題がある可能性がありますか?
1163 次
3 に答える
2
可能であれば、接続プールの使用を検討する必要があると思います。
そうすれば、接続/クローズのオーバーヘッドの作成について心配する必要はありません。
接続が必要な場合は、プールから取得できます。接続が完了したら、接続をプールに返す close() を呼び出します。
接続プールの仕組みを理解するには、このディスカッションを参照してください。
于 2012-09-21T18:46:11.973 に答える
2
接続プールについて読む必要があります。
C3PO、ボーンCP、DBCP
これは利用可能な最高で人気のある接続プールです。私は実稼働プロジェクトで BoneCP を使用しています。
于 2012-09-21T18:46:33.437 に答える
1
これにより、接続の確立/クローズに大きなオーバーヘッドが発生する可能性があります。
おっしゃる通り、接続の確立と終了は、頻繁に行われるとコストがかかる操作であることがわかります。
単一の接続マネージャー サーブレットを使用して、すべてのサーブレット間でグローバル接続を共有する (つまり、すべてのサーブレットが同じ接続を使用する) のはどうですか?
JDBC 仕様では接続が複数のスレッドによって共有されることを防げませんが、ドライバーの実装に依存する可能性があるため、これは悪い習慣と見なされます。そのため、データベース セッションごとに 1 つの接続を使用すると、コードの移植性と保守性が向上します。
JDBC 仕様では、DataSourceオブジェクトを使用して接続をプールし、上記のオーバーヘッドを回避することを推奨しています。
接続を取得するために、アプリケーションは次のいずれかと対話します。
- 1 つ以上の Driver 実装と連携する DriverManager クラス
また
- DataSource 実装
DataSource オブジェクトの使用は、アプリケーションの移植性を高め、コードのメンテナンスを容易にし、アプリケーションが接続プーリングと分散トランザクションを透過的に利用できるようにするため、推奨される方法です。データ ソースへの接続を確立するすべての J2EE コンポーネントは、DataSource オブジェクトを使用して接続を取得します。
于 2012-09-21T18:56:13.003 に答える