Grupo de conexiones o fuente de datos? ¿Qué debería poner en JNDI?

Question

¿Tiene más sentido tener un grupo de conexiones en el nivel JNDI o en el nivel de aplicación web? Por ejemplo, podría crear al javax.sql.DataSource simplemente así:

<Context antiJARLocking="true"> 
    <Resource name="jdbc/myDataSource" 
    auth="Container" 
    type="javax.sql.DataSource" 
    driverClassName="com.mysql.jdbc.Driver" 
    url="jdbc:mysql://localhost/myDataSource" user="user" password="password" /> 
</Context> 

y luego configurar la piscina en la primavera de esta manera:

<bean id="myDataSource" class="com.mchange.v2.c3p0.DataSources" 
    factory-method="pooledDataSource"> 
    <constructor-arg> 
    <jee:jndi-lookup jndi-name="java:comp/env/jdbc/myDataSource" /> 
    </constructor-arg> 
</bean> 

O, podría configurar la piscina directamente en sí mismo JNDI:

<Resource name="jdbc/myDataSource" 
    auth="Container" 
    factory="org.apache.naming.factory.BeanFactory" 
    type="com.mchange.v2.c3p0.ComboPooledDataSource" 
    driverClassName="com.mysql.jdbc.Driver" 
    jdbcUrl="jdbc:mysql://localhost/myDataSource" 
    user="user" password="password" 
    minPoolSize="3" 
    maxPoolSize="15" 
    maxIdleTime="5000" 
    idleConnectionTestPeriod="300" 
    acquireIncrement="3" /> 

Dejando esta primavera:

<jee:jndi-lookup id="myDataSource" jndi-name="java:comp/env/jdbc/myDataSource" /> 

En ambos casos, el bean spring de myDataSource sería una fuente de datos combinada de conexión c3p0, pero ¿cuál es mejor? Estoy pensando que tener el grupo en JNDI tiene más sentido, pero la desventaja de eso es que debe empujar su biblioteca c3p0 al nivel de contenedor de servlet, lo que podría causar conflictos con los servlets existentes si actualmente usan una versión diferente. Sin embargo, ponerlo en JNDI significa que sus aplicaciones no tienen que preocuparse por la agrupación en absoluto. ¿Qué piensan ustedes?

Answer 1

No es necesario poner en común la fuente de datos, obtenidos a partir de JNDI, como ya se agruparon :)

La única diferencia entre tener una piscina V.S. contenedor-manager el grupo de aplicaciones es que en el primer caso tiene la capacidad de controlar la carga de trabajo en el grupo utilizando las interfaces estándar (por ejemplo, la consola JBoss). A continuación, el administrador del servidor de aplicaciones gestiona la decisión de aumentar el tamaño de la agrupación, si es necesario. También puede cambiar aplicaciones a otro servidor de bases de datos (por ejemplo, migración planificada de MySQL a Oracle). La desventaja es que necesita un poco más de esfuerzo para configurar la fuente de datos de prueba JNDI para las pruebas de su unidad (consulte here).

Y en el segundo caso, sí, debe empaquetar ya sea DBCP o c3p0 más el controlador JDBC junto con su aplicación. En este caso, no es tan fácil recopilar estadísticas sobre todos los grupos para todas las aplicaciones que se ejecutan en Tomcat. Además, la migración al controlador JDBC más nuevo (MySQL 4 a MySQL 5) no se puede realizar para todas las aplicaciones a la vez. Y las propiedades de conexión están conectadas a su aplicación, incluso si usa un archivo .property (por lo tanto, es necesario cambiarlo para volver a ensamblar y volver a implementar el proyecto). Quizás no necesite todo eso, ya que solo tiene una aplicación, una base de datos y no tiene gastos administrativos.

Más temas sobre este tema:

• 10 pools with 5 connections v.s. 1 pool with 50 connection (eso es lo que sucede cuando cada aplicación comienza a utilizar su propia piscina)
• DBCP vs C3P0
• Connection pool implementations
• Why to use a connection pool?