Difference between configuring data source in persistence.xml and in spring configuration files

I've seen (and done) data source configuration in two ways (the code below is just for demo):

1) configuration inside persistence units, like:

<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 inside spring configuration files (like 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="databasePl开发者_StackOverflow社区atform" 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>

The question is: are there any pros and cons of each way, or it's just a matter of taste?

It makes a huge difference if you're in a JavaEE container.

More than personal preference, you're much better off if you follow the second approach with a few modifications.

In the first case, you're creating your own connection pool and do not profit from the existing connection pool in the container. Thus even if you configured your container to, say, a max of 20 simultaneous connections to the database, you can't guarantee this max as this new connection pool is not restrained by your configuration. Also, you don't profit from any monitoring tools your container provides you.

In the second case, you're also creating your own connection pool, with the same disadvantages as above. However, you can isolate the definition of this spring bean and only use it in test runs.

Your best bet is to look up the container's connection pool via JNDI. Then you are sure to respect the data source configurations from the container.

Use this for running tests.

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

Use this when deploying to a JavaEE container

<!-- datasource.xml -->
<jee:jndi-lookup id="domainDataSource" jndi-lookup="jndi/MyDataSource" />

• Remember to set the JEE schema
• Although Tomcat is not a full JavaEE container, it does manage data sources via JNDI, so this answer still applies.

It is strictly personal preference.

My suggestion would be to use Spring's configuration if you are using Spring already. Its purpose is dependency injection and management so let it do its job with respect to your dependency on a database. If, however, you are not already using Spring, stick with the persistence configuration considering that this will keep your project simpler while still functional. I will suggest though that any project that needs Hibernate to interact with a database is probably big enough to condone using Spring within.