Pool di connessioni o origine dati? Quale dovrei inserire in JNDI?

Question

Ha senso avere un pool di connessioni a livello JNDI o a livello di webapp? Per esempio, ho potuto creare al semplice javax.sql.DataSource così:

<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> 

e quindi configurare la piscina in primavera così:

<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> 

Oppure, ho potuto configurare la piscina direttamente in JNDI per sé:

<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" /> 

Lasciando questa primavera:

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

In entrambi i casi, il bean spring myDataSource sarebbe un'origine dati pool di connessioni c3p0, ma quale è il migliore? Penso che avere il pool in JNDI abbia più senso, ma il lato negativo è che devi spingere la tua lib di c3p0 al livello del servlet container che potrebbe causare conflitti con i servlet esistenti se attualmente usano una versione diversa. Tuttavia, inserendolo in JNDI significa che le applicazioni non devono preoccuparsi del pooling. Cosa pensate?

Answer 1

Non è necessario mettere in comune l'origine dei dati, ottenuti da JNDI, in quanto è già riunito :)

L'unica differenza tra l'avere un contenitore-manager piscina V.S. Il pool di applicazioni è che nel primo caso è possibile monitorare il carico di lavoro sul pool utilizzando le interfacce standard (ad esempio la console JBoss). Quindi l'amministratore del server delle applicazioni gestisce la decisione sull'aumento delle dimensioni del pool, se necessario. Può anche passare applicazioni a un altro server DB (ad esempio, migrazione pianificata da MySQL a Oracle). Lo svantaggio è che sono necessari un po 'più di sforzi per impostare l'origine dei dati di test JNDI per i test dell'unità (vedere here).

E in 2 ° caso, sì, è necessario pacchettizzare DBCP o c3p0 più il driver JDBC insieme all'applicazione. In questo caso non è così facile raccogliere le statistiche di tutti i pool per tutte le applicazioni in esecuzione in Tomcat. Non è possibile eseguire la migrazione a un nuovo driver JDBC (da MySQL 4 a MySQL 5) per tutte le applicazioni contemporaneamente. E le proprietà di connessione sono collegate alla tua applicazione, anche se utilizzi un file .property (quindi la modifica che richiede il riassemblaggio e la ridistribuzione del progetto). Forse non hai bisogno di tutto questo, dato che hai solo un'applicazione, un DB e nessun overhead di gestione.

Altri argomenti su questo tema:

• 10 pools with 5 connections v.s. 1 pool with 50 connection (questo è ciò che succede quando ogni applicazione inizia a utilizzare la sua piscina)
• DBCP vs C3P0
• Connection pool implementations
• Why to use a connection pool?