Glassfish や Websphere などのアプリケーション サーバーにデプロイされたアプリケーションの一部としてデータベース接続プール (Commons DBCP や c3p0 など) を実行しても安全ですか? 安全性やパフォーマンスを確保するために、スタンドアロン アプリケーションに対して実行する必要がある追加の手順はありますか?
更新、理由の明確化 - 私が念頭に置いているユースケースでは、熟練したエンドユーザーが実行時に新しいデータソースを定義する必要がある可能性があります - 必要に応じて、データソースの変更はアプリケーションの機能の一部です。その場でコンテナー管理プールを作成して使用することはできないと思いますか?
私の知る限り、それは機能しますが、もちろんアプリをエスケープします。サーバー管理機能。
また、展開解除または再展開がどのように行われるのか、接続が正しく破棄されるのかどうかも完全にはわかりません。しかし、それは小さな安全上の詳細と見なすことができます: 不適切に処分された場合、接続は単にタイムアウトになると思います. また、分散トランザクション マネージャーと統合された XA データ ソースで機能するかどうかも完全にはわかりません。
つまり、アプリを使用しています。サーバー プールは、通常、構成ファイルで JNDI 名を構成することです。その後、監視、管理コンソールからの構成、負荷管理などを無料で利用できます。
実際、使用する AS に応じて、コンテナー管理のデータソースを作成できます。
たとえば、Weblogic には、スクリプトによってサーバーを構成するために独自の WLST (Weblogic シェル) などで使用される広範な管理 APIがあります。もちろん、これは Java API です。データソースを作成および構成するメソッドもあります。
もう 1 つのルートは、JMX ベースの構成です。最新の AS はすべて、JMX コンテナーとして公開されます。JMX 経由でもデータソースを作成できます。
必要なのは、アプリケーションの管理者権限を付与することだけです (つまり、ユーザー名とパスワードを提供します)。
コンテナー管理 DS の利点は、クラスター化できることです。また、標準の AS UI を使用して人間が管理することもできます。
それがうまくいかない場合は、アプリケーション管理の DSをいつでもいくつでも作成できることを確認してください。特定の管理対象サーバーにバインドされることに注意してください (その定義の手動クラスタリングを実装しない限り)。
なぜあなたがしたいのかわかりません。アプリ サーバーが提供する接続プールを使用してみませんか?
更新: アプリ サーバーをバウンスせずにその場で新しいプールを作成できるとは思いませんが、間違っている可能性があります。それが正しければ、Commons DBCP や C3P0 が役立つとは思えません。