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

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

13 голосов
/ 07 октября 2011

Имеет ли смысл иметь пул соединений на уровне JNDI или на уровне веб-приложения? Например, я мог бы просто создать на 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" />

Уход этой весной: 

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

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

1 Ответ

24 голосов
/ 09 октября 2011

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

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

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

Больше тем на эту тему:

...