J'ai vu (et fait) la configuration de la source de données de deux manières (le code ci-dessous est juste pour la démo):
1) configuration à l'intérieur des unités de persistance, comme:
<persistence-unit name="LocalDB" transaction-type="RESOURCE_LOCAL">
<class>domain.User</class>
<exclude-unlisted-classes>true</exclude-unlisted-classes>
<properties>
<property name="hibernate.connection.driver_class" value="org.hsqldb.jdbcDriver"/>
<property name="hibernate.connection.url" value="jdbc:hsqldb:hsql://localhost"/>
<property name="hibernate.hbm2ddl.auto" value="create"/>
<property name="hibernate.c3p0.min_size" value="5"/>
....
<property name="hibernate.dialect" value="org.hibernate.dialect.HSQLDialect"/>
</properties>
</persistence-unit>
2) configuration dans les fichiers de configuration de printemps (comme applicationContext.xml):
<bean id="domainEntityManagerFactory" class="org.springframework.orm.jpa.LocalContainerEntityManagerFactoryBean">
<property name="persistenceUnitName" value="JiraManager"/>
<property name="dataSource" ref="domainDataSource"/>
<property name="jpaVendorAdapter">
<bean class="org.springframework.orm.jpa.vendor.HibernateJpaVendorAdapter">
<property name="generateDdl" value="false"/>
<property name="showSql" value="false"/>
<property name="databasePlatform" value="${hibernate.dialect}"/>
</bean>
</property>
</bean>
<bean id="domainDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass" value="${db.driver}" />
<property name="jdbcUrl" value="${datasource.url}" />
<property name="user" value="${datasource.username}" />
<property name="password" value="${datasource.password}" />
<property name="initialPoolSize" value="5"/>
<property name="minPoolSize" value="5"/>
.....
</bean>
La question est: y a-t-il des avantages et des inconvénients de chaque façon, ou c'est juste une question de goût?
Cela fait une énorme différence si vous êtes dans un conteneur JavaEE.
Plus que vos préférences personnelles, vous êtes bien mieux si vous suivez la deuxième approche avec quelques modifications.
Dans le premier cas, vous créez votre propre pool de connexions et ne profitez pas du pool de connexions existant dans le conteneur. Ainsi, même si vous avez configuré votre conteneur pour, disons, un maximum de 20 connexions simultanées à la base de données, vous ne pouvez pas garantir ce maximum car ce nouveau pool de connexions n'est pas restreint par votre configuration. De plus, vous ne bénéficiez d'aucun outil de surveillance que votre conteneur vous fournit .
Dans le second cas, vous créez également votre propre pool de connexions , avec les mêmes inconvénients que ci-dessus. Cependant, vous pouvez isoler la définition de ce spring bean et ne l'utiliser que dans les tests.
Votre meilleur pari est de rechercher le pool de connexions du conteneur via JNDI . Ensuite, vous êtes sûr de respecter les configurations de source de données du conteneur.
<!-- datasource-test.xml -->
<bean id="domainDataSource" class="com.mchange.v2.c3p0.ComboPooledDataSource" destroy-method="close">
<property name="driverClass" value="${db.driver}" />
<property name="jdbcUrl" value="${datasource.url}" />
<property name="user" value="${datasource.username}" />
<property name="password" value="${datasource.password}" />
<property name="initialPoolSize" value="5"/>
<property name="minPoolSize" value="5"/>
.....
</bean>
<!-- datasource.xml -->
<jee:jndi-lookup id="domainDataSource" jndi-lookup="jndi/MyDataSource" />
C'est une préférence strictement personnelle.
Ma suggestion serait d'utiliser la configuration de Spring si vous utilisez déjà Spring. Son but est l'injection et la gestion des dépendances, alors laissez-le faire son travail en ce qui concerne votre dépendance à une base de données. Si, cependant, vous n'utilisez pas déjà Spring, tenez-vous-en à la configuration de persistance, car cela simplifiera votre projet tout en restant fonctionnel. Je suggérerai cependant que tout projet qui a besoin d'Hibernate pour interagir avec une base de données est probablement assez grand pour tolérer l'utilisation de Spring à l'intérieur.