web-dev-qa-db-ja.com

Application ServerJDBCリソースのDataSourceまたはConnectionPoolDataSource

アプリケーションサーバーでJNDIJDBC接続プールを作成するとき、私は常にタイプをjavax.sql.ConnectionPoolDataSourceとして指定しました。プールされていない接続よりもプールされた接続を好むのは常に自然に思えたので、私はあまり考えすぎたことはありませんでした。

ただし、いくつかの例を見ると（ 特にTomcatの場合 ）、それらがjavax.sql.DataSourceを指定していることに気付きました。さらに、maxIdleとmaxWaitの設定があり、これらの接続もプールされているように見えます。 Glassfishでは、選択したデータソースのタイプに関係なく、これらのパラメータも使用できます。

  • javax.sql.DataSourceはアプリケーションサーバー（またはサーブレットコンテナ）にプールされていますか？
  • javax.sql.ConnectionPoolDataSourceよりもjavax.sql.DataSourceを選択する（またはその逆）ことには、（もしあれば）どのような利点がありますか？
javadatabaseconfigurationconnection-poolingapplication-server
24
Vinnie

はい、TomcatはJNDIコンテキストリソースとして定義されたデータソースに対してデフォルトでApacheDBCPプーリングを使用します。

http://Tomcat.Apache.org/Tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources のドキュメントから

注-Tomcatでのデフォルトのデータソースサポートは、CommonsプロジェクトのDBCP接続プールに基づいています。ただし、以下で説明するように、独自のカスタムリソースファクトリを作成することにより、javax.sql.DataSourceを実装する他の接続プールを使用することができます。

Tomcat 6ソースを掘り下げると、この方法で接続ファクトリを取得することが明らかになりました（Contextの「factory」属性を使用して独自のソースを指定しない場合）。

ObjectFactory factory = (ObjectFactory)Class.forName(System.getProperty("javax.sql.DataSource.Factory", "org.Apache.Tomcat.dbcp.dbcp.BasicDataSourceFactory")).newInstance();

また、javax.naming.spi.ObjectFactoryを実装するorg.Apache.Tomcat.dbcp.dbcp.BasicDataSourceFactoryは、DataSourceインスタンスの作成を処理します。 http://www.jarvana.com/jarvana/view/org/Apache/ Tomcat/tomcat-dbcp/7.0.2/Tomcat-dbcp-7.0.2-sources.jar！/org/Apache/Tomcat/dbcp/dbcp/BasicDataSourceFactory.java？format = ok

Org.Apache.Tomcat.dbcp.dbcp.BasicDataSourceのインスタンスを作成しているようです： http://www.jarvana.com/jarvana/view/org/Apache/Tomcat/tomcat-dbcp/7.0.2/ Tomcat-dbcp-7.0.2-sources.jar！/org/Apache/Tomcat/dbcp/dbcp/BasicDataSource.java？format = ok

奇妙なことに、このクラスはConnectionPoolDataSource自体を実装しておらず、BasicDataSourceによって内部的に返されるorg.Apache.Tomcat.dbcp.dbcp.PoolingDataSourceも実装していません http://www.jarvana.com/jarvana/view/org /Apache/Tomcat/tomcat-dbcp/7.0.2/Tomcat-dbcp-7.0.2-sources.jar!/org/Apache/Tomcat/dbcp/dbcp/PoolingDataSource.java?format=ok

したがって、データソースをjavax.sql.ConnectionPoolDataSourceとして構成したときに、カスタム定義のファクトリも使用したと思います（これは単なる推測ですが、そうでない場合は、Tomcatでクラスキャストの例外が発生する可能性があります。これは、プールが実際には提供しないためです。 javax.sql.ConnectionPoolDataSourceのインスタンス。javax.sql.DataSourceのみ）。

したがって、特定のケースの長所または短所に関する質問に答えるには、Apache DBCPを、使用したDataSourceファクトリのプーリングメカニズムと比較する必要があります。

8
mvmn

Java docsに関しては、これが含まれています：

DataSource Java 7 API

DataSourceインターフェースは、ドライバーベンダーによって実装されます。実装には次の3つのタイプがあります。

基本的な実装-標準のConnectionオブジェクトを生成します

接続プールの実装-接続プールに自動的に参加する接続オブジェクトを生成します。この実装は、中間層の接続プールマネージャで機能します。

分散トランザクションの実装-分散トランザクションに使用できるConnectionオブジェクトを生成し、ほとんどの場合、接続プーリングに参加します。この実装は、中間層のトランザクションマネージャーで機能し、ほとんどの場合、接続プールマネージャーで機能します。

PooledConnection Java 7 API

アプリケーションプログラマーは、PooledConnectionインターフェイスを直接使用しません。むしろ、接続のプーリングを管理する中間層インフラストラクチャによって使用されます。

アプリケーションがメソッドDataSource.getConnectionを呼び出すと、Connectionオブジェクトが返されます。 接続プーリングが実行されている場合、そのConnectionオブジェクトは、実際には物理接続であるPooledConnectionオブジェクトへのハンドルです。

接続プールマネージャー、通常はアプリケーションサーバー、はPooledConnectionオブジェクトのプールを維持します..。

したがって、最終的にはDataSourceクラスとConnectionクラスを使用し、PooledConnection/ConnectionPoolDataSource、あなたが幸せで普通のプログラマーなら。

別の話であるアプリケーションサーバーを実装している場合...

5
MrJames

私の理解では、ConnectionPoolDataSourceの唯一の目的は、JDBCドライバーによるnativeプーリングを実装するPooledConnectionへのアクセスを許可することです。この場合、アプリケーションサーバーはこのネイティブインターフェイスを使用して接続プールを実装できます。

単純なDataSourceを使用する場合、appserverはネイティブではなく独自のプーリングを使用します。

どのアプローチが最適かは言えません。

5
Sergey Aslanov