Пул соединений или источник данных? Что я должен поставить в JNDI?

Имеет ли смысл иметь пул соединений на уровне JNDI или на уровне webapp? Например, я мог бы просто создать javax.sql.DataSource:

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

а затем настройте пул в Spring следующим образом:

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

Или я мог бы настроить пул непосредственно в JNDI:

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

Оставляя это spring:

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

В обоих случаях myDataSource Spring bean будет источником данных с пулом c3p0, но какой из них лучше? Я думаю, что наличие пула в JNDI имеет наибольший смысл, но недостатком является то, что вы должны подтолкнуть ваш c3p0 lib к уровню контейнера сервлета, который может вызвать конфликты с существующими сервлетами, если они в настоящее время используют другую версию. Однако, вставляя его в JNDI, ваши приложения не должны беспокоиться об объединении вообще. Что вы думаете?

Ответы

Ответ 1

Вам не нужно объединять источник данных, полученный из JNDI, поскольку он уже объединен:)

Единственная разница между наличием пула контейнера-менеджера v.s. пул приложений - это то, что в 1-м случае у вас есть возможность контролировать рабочую нагрузку в пуле с использованием стандартных интерфейсов (например, консоли JBoss). Затем администратор сервера приложений управляет решением об увеличении размера пула, если это необходимо. Он также может переключать приложения на другой сервер БД (например, планируемый переход от MySQL к Oracle). Недостатком является то, что вам нужно немного больше усилий, чтобы настроить исходный источник данных JNDI для ваших модульных тестов (см. здесь).

И во втором случае, да, вам нужно упаковать либо DBCP, либо c3p0 плюс драйвер JDBC вместе с вашим приложением. В этом случае собрать статистику о всех пулах для всего приложения, запущенного в Tomcat, не так-то просто. Кроме того, миграция на новый драйвер JDBC (MySQL 4 до MySQL 5) не может быть выполнена для всех приложений одновременно. И свойства подключения подключены к вашему приложению, даже если вы используете файл .property (поэтому изменение требует повторной сборки и перераспределения проекта). Возможно, вам не нужно все это, так как у вас есть только приложение, одна БД и служебные накладные расходы.

Другие темы на эту тему: