java - not - DataSource o ConnectionPoolDataSource para los recursos JDBC de Application Server
class name is wrong or classpath is not set for com mysql jdbc jdbc2 optional mysqldatasource (3)
Sí, Tomcat utiliza la agrupación de Apache DBCP por defecto para los recursos de datos definidos como recursos de contexto JNDI.
De la documentación en http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources
NOTA - El soporte de fuente de datos predeterminado en Tomcat se basa en el conjunto de conexiones DBCP del proyecto Commons. Sin embargo, es posible utilizar cualquier otro grupo de conexiones que implemente javax.sql.DataSource escribiendo su propia fábrica de recursos personalizada, como se describe a continuación.
Las fuentes Digging Tomcat 6 revelaron que obtienen la fábrica de conexiones de esta manera (en caso de que no especifiques la tuya usando el atributo "factory" de Context):
ObjectFactory factory = (ObjectFactory)Class.forName(System.getProperty("javax.sql.DataSource.Factory", "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory")).newInstance();
Y org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory que implementa javax.naming.spi.ObjectFactory se encarga de crear instancias de 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
Veo que crean instancias de 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
Por extraño que parezca, esta clase no implementa ConnectionPoolDataSource en sí, tampoco lo hace org.apache.tomcat.dbcp.dbcp.PoolingDataSource, que es devuelto internamente por 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/PoolingDataSource.java?format=ok
Así que supongo que cuando configuró sus DataSources como javax.sql.ConnectionPoolDataSource, también usó alguna fábrica definida a la medida (es solo una suposición, pero supongo que de lo contrario tendría excepciones de clase en Tomcat, ya que su agrupación en realidad no proporciona instancias de javax.sql.ConnectionPoolDataSource, solo javax.sql.DataSource).
Por lo tanto, para responder preguntas sobre las ventajas o desventajas de un caso particular, debe comparar el DBCP de Apache con el mecanismo de puesta en común en su fábrica de DataSource, cualquiera que haya utilizado.
Al crear conjuntos de conexiones JNDI JDBC en un servidor de aplicaciones, siempre especifiqué el tipo como javax.sql.ConnectionPoolDataSource . Nunca pensé demasiado, ya que siempre parecía natural preferir las conexiones agrupadas sobre las no agrupadas.
Sin embargo, al mirar algunos ejemplos ( específicamente para Tomcat ) noté que especifican javax.sql.DataSource . Además, parece que hay configuraciones para maxIdle y maxWait dan la impresión de que estas conexiones también se agrupan. Glassfish también permite estos parámetros independientemente del tipo de fuente de datos seleccionada.
- ¿
javax.sql.DataSourceagrupado en un servidor de aplicaciones (o contenedor de servlets)? - ¿Qué ventajas (si existen) existen para elegir
javax.sql.ConnectionPoolDataSourcesobrejavax.sql.DataSource(o viceversa)?
Tengo entendido que el único propósito de ConnectionPoolDataSource es otorgar acceso a PooledConnection que implementa el agrupamiento nativo mediante el controlador JDBC. En este caso, el servidor de aplicaciones puede implementar la agrupación de conexiones utilizando esta interfaz nativa.
Al usar DataSource simple, el servidor de aplicaciones usa su propia agrupación en lugar de nativa.
No puedo decir qué enfoque es el mejor.
En cuanto a los documentos de Java, contiene esto:
La interfaz de DataSource es implementada por un proveedor de controladores. Hay tres tipos de implementaciones:
Implementación básica: produce un objeto de conexión estándar
Implementación de agrupación de conexiones: produce un objeto de conexión que participará automáticamente en la agrupación de conexiones. Esta implementación funciona con un administrador de agrupación de conexiones de nivel medio.
Implementación de transacciones distribuidas: produce un objeto de conexión que se puede usar para transacciones distribuidas y casi siempre participa en la agrupación de conexiones. Esta implementación funciona con un administrador de transacciones de nivel medio y casi siempre con un administrador de agrupación de conexiones.
API de PooledConnection Java 7
Un programador de aplicaciones no usa la interfaz PooledConnection directamente; más bien, es utilizado por una infraestructura de nivel medio que administra la agrupación de conexiones.
Cuando una aplicación llama al método DataSource.getConnection, recupera un objeto Connection. Si se realiza la agrupación de conexiones, ese objeto Connection es en realidad un identificador de un objeto PooledConnection , que es una conexión física.
El administrador del grupo de conexiones , generalmente el servidor de aplicaciones, mantiene un grupo de objetos PooledConnection ....
Así que al final solo usas las clases DataSource y Connection y nunca PooledConnection / ConnectionPoolDataSource , si eres un programador feliz y normal.
Si están implementando un servidor de aplicaciones, eso es otra historia ...