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

Question

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

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>

Вопрос в том, есть ли плюсы и минусы в каждом случае, или это просто вопрос вкуса?

Answer 1

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

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

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

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

Лучше всего посмотреть пул соединений контейнера через 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, поэтому этот ответ по-прежнему применяется.

Answer 2

Это сугубо личное предпочтение.

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