A la hora de crear JNDI conexión JDBC piscinas en un servidor de aplicaciones, siempre he especificado el tipo como javax.sql.ConnectionPoolDataSource. Yo nunca le dio demasiada importancia, ya que siempre parecía natural prefieren las conexiones agrupadas sobre los no agrupados.

Sin embargo, en mirar algunos ejemplos ( específicamente para Tomcat ), me di cuenta de que se especifica javax.sql.DataSource. Además, parece que hay ajustes para maxIdle y maxWait dando la impresión de que estas conexiones están agrupadas así. Glassfish también permite a estos parámetros, independientemente del tipo de origen de datos seleccionado.

  • Son javax.sql.DataSource agrupadas en un servidor de aplicaciones (o contenedor de servlets)?
  • Lo que (si cualquier) ventajas hay para elegir javax.sql.ConnectionPoolDataSource más de javax.sql.DataSource (o viceversa)?
InformationsquelleAutor Vinnie | 2011-06-28

3 Comentarios

  1. 8

    Sí, Tomcat hace uso de Apache DBCP la agrupación por omisión para Orígenes de datos que se define como el Contexto JNDI recursos.

    De la documentación en
    http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

    NOTA – El valor predeterminado de la fuente de datos de soporte
    en Tomcat se basa en el DBCP
    grupo de conexión de los Comunes
    proyecto. Sin embargo, es posible
    el uso de cualquier otro grupo de conexión que
    implementa javax.sql.Origen de datos, por
    la escritura de sus propios recursos
    la fábrica, como se describe a continuación.

    La excavación de Tomcat 6 fuentes revelaron que ellos obtención de la conexión de la fábrica de esta manera (en caso de que cuando no se especifica su propio Contexto «de fábrica» atributo):

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

    Y org.apache.tomcat.el dbcp.el dbcp.BasicDataSourceFactory que implementa javax.nomenclatura.spi.ObjectFactory se ocupa de la creación del origen de datos de instancias:
    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 crear instancias de org.apache.tomcat.el dbcp.el 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 sí mismo, tampoco org.apache.tomcat.el dbcp.el dbcp.PoolingDataSource, que se devuelve 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 has configurado tus Orígenes como javax.sql.ConnectionPoolDataSource también utiliza algunas definido de fábrica (es sólo una conjetura, pero supongo que de lo contrario tendrías clase elenco de excepciones en Tomcat, ya que su agrupación no proporcionar instancias de javax.sql.ConnectionPoolDataSource, sólo javax.sql.Origen de datos).

    Por lo tanto, para responder a las preguntas acerca de las ventajas o desventajas de caso en particular se debe comparar Apache DBCP contra mecanismo de agrupación en el origen de datos de fábrica, cualquiera que usted utiliza.

    • A la derecha. En realidad sólo he configurado el ConnectionPoolDataSource en Glassfish y especifica su com.mysql.jdbc.jdbc2.opcional.MysqlConnectionPoolDataSource. Gracias por toda la gran información!
    • Eres bienvenido. Por favor vote-up / indicar como respuesta correcta (-:
  2. 5

    Mi entendimiento es que el sólo propósito de ConnectionPoolDataSource es dar acceso a PooledConnection que implementa nativo la agrupación del controlador JDBC. En este caso el servidor de aplicación puede implementar conexiones de la agrupación de uso de esta interfaz nativa.

    Cuando el uso de simples DataSource, appserver utiliza su propia agrupación en lugar de los nativos.

    No se puede decir cuál es el mejor enfoque.

  3. 5

    Como Java docs contiene esto:

    Origen de datos de la API de Java 7

    El origen de datos de la interfaz es implementada por un proveedor del controlador. Hay tres tipos de implementaciones:

    Implementación básica — produce una Conexión estándar de objetos

    La agrupación de conexiones de implementación, produce un objeto de Conexión que automáticamente va a participar en la agrupación de conexiones. Esta aplicación funciona con un nivel medio de agrupación de conexiones de administrador.

    De transacciones distribuidas de la aplicación — produce un objeto de Conexión que puede ser utilizado para las transacciones distribuidas y casi siempre participa en la agrupación de conexiones. Esta aplicación funciona con un nivel medio del administrador de transacciones y casi siempre con una conexión a la agrupación de administrador.

    PooledConnection de la API de Java 7

    Un programador de la aplicación no utiliza la PooledConnection interfaz directamente; más bien, es utilizado por un nivel medio de infraestructura que gestiona la agrupación de conexiones.

    Cuando una aplicación llama al método origen de datos.getConnection, se vuelve un objeto de Conexión. Si la agrupación de conexiones que se ha hecho, que el objeto de Conexión es en realidad un identificador para un PooledConnection objeto, que es una conexión física.

    La conexión del administrador del grupo de, normalmente el servidor de aplicaciones, mantiene un grupo de PooledConnection objetos ….

    Así que al final, usted sólo tiene que utilizar DataSource y Conexión clases y nunca PooledConnection /ConnectionPoolDataSource, si usted es feliz y normal programador.

    Si son la implementación de un Servidor de Aplicaciones que es otra historia…

    • Esta es la verdadera medida de lo que va, pero no responde a la pregunta. Como una persona que llama de por ejemplo, DataSource#getConnection() tienes razón: esa es la única manera de que una persona interacciona con un appserver suministrado por el grupo de conexión. Pero como administrador de la configuración de la piscina en el primer lugar (que es lo que esta pregunta está preguntando acerca de), es en realidad completamente indeterminado. Consulte stackoverflow.com/questions/12826191/….

Dejar respuesta

Please enter your comment!
Please enter your name here