DataSource или ConnectionPoolDataSource для ресурсов JDBC сервера приложений

При создании пулов соединений JNDI JDBC на сервере приложений я всегда указывал тип javax.sql.ConnectionPoolDataSource. Я никогда особо не задумывался об этом, так как всегда казалось естественным предпочитать соединения в пуле соединениям без пула.

Однако, глядя на некоторые примеры (специально для Tomcat ) Я заметил, что они указывают javax.sql.DataSource. Кроме того, кажется, что есть настройки для maxIdle и maxWait, создающие впечатление, что эти соединения также объединены. Glassfish также позволяет использовать эти параметры независимо от выбранного типа источника данных.

  • Объединены ли javax.sql.DataSource в сервер приложений (или контейнер сервлетов)?
  • Каковы (если есть) преимущества выбора javax.sql.ConnectionPoolDataSource вместо javax.sql.DataSource (или наоборот)?

java database configuration connection-pooling application-server
person Vinnie    schedule 28.06.2011    source источник
comment
Я никогда не использовал ConnectionPoolDataSource; это всегда DataSource на Tomcat, WebLogic и JBOSS.   -  person duffymo    schedule 28.06.2011
comment
Аналогично: Разница между DataSource и ConnectionPoolDataSource   -  person Basil Bourque    schedule 21.05.2017

Ответы (3)


arrow_upward
8
arrow_downward

Да, Tomcat по умолчанию использует пул Apache DBCP для источников данных, определенных как ресурсы контекста JNDI.

Из документации по адресу http://tomcat.apache.org/tomcat-7.0-doc/jndi-resources-howto.html#JDBC_Data_Sources

ПРИМЕЧАНИЕ. Поддержка источника данных по умолчанию в Tomcat основана на пуле соединений DBCP из проекта Commons. Однако можно использовать любой другой пул соединений, который реализует javax.sql.DataSource, написав собственную фабрику ресурсов, как описано ниже.

Копание источников Tomcat 6 показало, что они получают фабрику соединений таким образом (в случае, если вы не укажете свою собственную, используя атрибут «фабрика» контекста):

ObjectFactory factory = (ObjectFactory)Class.forName(System.getProperty("javax.sql.DataSource.Factory", "org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory")).newInstance();

А org.apache.tomcat.dbcp.dbcp.BasicDataSourceFactory, реализующий javax.naming.spi.ObjectFactory, заботится о создании экземпляров DataSource: http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSourceFactory.java?format=ok

Я вижу, что они создают экземпляры org.apache.tomcat.dbcp.dbcp.BasicDataSource: http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2./tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/BasicDataSource.java?format=ok

Как ни странно, этот класс не реализует ни сам ConnectionPoolDataSource, ни org.apache.tomcat.dbcp.dbcp.PoolingDataSource, возвращаемый внутри BasicDataSource http://www.jarvana.com/jarvana/view/org/apache/tomcat/tomcat-dbcp/7.0.2/tomcat-dbcp-7.0.2-sources.jar!/org/apache/tomcat/dbcp/dbcp/PoolingDataSource.java?format=ok

Итак, я предполагаю, что когда вы настроили свои источники данных как javax.sql.ConnectionPoolDataSource, вы также использовали какую-то пользовательскую фабрику (это просто предположение, но я полагаю, что в противном случае у вас были бы исключения приведения классов в Tomcat, поскольку их объединение на самом деле не обеспечивает экземпляры javax.sql.ConnectionPoolDataSource, только javax.sql.DataSource).

Таким образом, чтобы ответить на вопросы о преимуществах или недостатках конкретного случая, вы должны сравнить Apache DBCP с механизмом пула в вашей фабрике DataSource, какой бы из них вы ни использовали.

person mvmn    schedule 28.06.2011
comment
Верно. На самом деле я только настроил ConnectionPoolDataSource в Glassfish и указал его com.mysql.jdbc.jdbc2.Optional.MysqlConnectionPoolDataSource. Спасибо за отличную информацию! - person Vinnie; 28.06.2011
comment
Пожалуйста. Пожалуйста, проголосуйте за / укажите правильный ответ (-: - person mvmn; 28.06.2011

arrow_upward
5
arrow_downward

Насколько я понимаю, единственной целью ConnectionPoolDataSource является предоставление доступа к PooledConnection, который реализует собственный пул с помощью драйвера JDBC. В этом случае сервер приложений может реализовать пул соединений, используя этот собственный интерфейс.

При использовании простого DataSource сервер приложений использует собственный пул вместо собственного.

Не могу сказать, какой подход лучше.

person Sergey Aslanov    schedule 28.06.2011

arrow_upward
5
arrow_downward

Что касается документов Java, он содержит следующее:

API DataSource Java 7

Интерфейс DataSource реализуется поставщиком драйвера. Существует три типа реализации:

Базовая реализация -- создает стандартный объект Connection

Реализация пула соединений — создает объект Connection, который автоматически участвует в пуле соединений. Эта реализация работает с менеджером пула соединений среднего уровня.

Реализация распределенной транзакции — создает объект Connection, который может использоваться для распределенных транзакций и почти всегда участвует в пуле соединений. Эта реализация работает с диспетчером транзакций среднего уровня и почти всегда с диспетчером пула соединений.

Java 7 API PooledConnection

Разработчик приложений не использует интерфейс PooledConnection напрямую; скорее, он используется инфраструктурой среднего уровня, которая управляет объединением соединений.

Когда приложение вызывает метод DataSource.getConnection, оно возвращает объект Connection. Если создается пул соединений, этот объект Connection фактически является дескриптором объекта PooledConnection, который является физическим соединением.

Диспетчер пула соединений, обычно сервер приложений, поддерживает пул объектов PooledConnection....

Так что в итоге вы просто используете классы DataSource и Connection и никогда не используете PooledConnection/ConnectionPoolDataSource, если вы счастливый и нормальный программист.

Если внедряете сервер приложений, это другая история...

person MrJames    schedule 20.03.2012
comment
Это верно, насколько это возможно, но не отвечает на вопрос. Как вызывающая сторона of, например. DataSource#getConnection() вы правы: это единственный способ, которым вызывающая сторона взаимодействует с пулом соединений, предоставляемым сервером приложений. Но как администратор, настраивающий пул в первую очередь (о чем и спрашивает этот вопрос), на самом деле это совершенно не указано. См. stackoverflow.com/questions/12826191/. - person Laird Nelson; 11.10.2012