Разница между настройкой источника данных в файлах persistence.xml и spring

Я видел (и сделал) конфигурацию источника данных двумя способами (ниже приведен код для демонстрации):

1) конфигурация внутри единиц сохранения, например:

<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) конфигурацию внутри конфигурационных файлов spring (например, 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>

Вопрос: есть ли какие-либо плюсы и минусы каждого из способов, или это просто вопрос вкуса?

Ответы

Ответ 1

Это имеет огромное значение, если вы находитесь в контейнере JavaEE.

Больше, чем личное предпочтение, вам намного лучше, если вы будете следовать второму подходу с несколькими изменениями.

В первом случае вы создаете свой собственный пул соединений и не получаете прибыль от существующего пула подключений в контейнере. Таким образом, даже если вы сконфигурировали свой контейнер, скажем, максимум 20 одновременных подключений к базе данных, вы не можете гарантировать этот максимум, поскольку этот новый пул соединений не сдерживается вашей конфигурацией. Кроме того, вы не получаете прибыль от каких-либо средств мониторинга, которые предоставляет ваш контейнер.

Во втором случае вы также создаете свой собственный пул соединений с теми же недостатками, что и выше. Однако вы можете выделить определение этого spring bean и использовать его только в тестовых прогонах.

Лучше всего найти пул подключений к контейнеру через JNDI. Тогда вы обязательно будете уважать конфигурацию источника данных из контейнера.

Используйте это для запуска тестов.

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

Используйте это при развертывании в контейнере JavaEE

<!-- datasource.xml -->
<jee:jndi-lookup id="domainDataSource" jndi-lookup="jndi/MyDataSource" />
  • Не забудьте установить схему JEE
  • Хотя Tomcat не является полным контейнером JavaEE, он управляет источниками данных через JNDI, поэтому этот ответ по-прежнему применяется.

Ответ 2

Это личное предпочтение.

Мое предложение было бы использовать конфигурацию Spring, если вы уже используете Spring. Его целью является инъекция и управление зависимостями, поэтому пусть это выполняет свою работу в зависимости от вашей зависимости от базы данных. Если, однако, вы еще не используете Spring, придерживайтесь конфигурации персистентности, учитывая, что это упростит ваш проект, пока он все еще функционирует. Я предположим, что любой проект, который требует Hibernate для взаимодействия с базой данных, вероятно, достаточно велик, чтобы потворствовать использованию Spring внутри.