DataSource или ConnectionPoolDataSource для ресурсов JDBC сервера приложений
При создании пулов соединений JNDI JDBC на сервере приложений я всегда указывал тип как javax.sql.ConnectionPoolDataSource . Я никогда особо не задумывался об этом, поскольку всегда казалось естественным отдавать предпочтение объединенным соединениям перед не объединенными.
Однако, глядя на некоторые примеры ( специально для Tomcat ), я заметил, что они указывают ] javax.sql.DataSource . В дальнейшем,похоже, есть настройки для maxIdle и maxWait , создающие впечатление, что эти соединения также объединены в пул. Glassfish также поддерживает эти параметры независимо от типа выбранного источника данных.
- Объединены ли
javax.sql.DataSourceв пул на сервере приложений (или контейнере сервлета)? - Какие (если есть) преимущества там для выбора
javax.sql.ConnectionPoolDataSourceвместоjavax.sql.DataSource(или наоборот)?
2 ответа
Да, 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/jarvan а / вид / орг / Apache / Tomcat / кот-ДБХП / 7.0.2 / кот-ДБХП-7.0.2-sources.jar! /org/apache/tomcat/dbcp/dbcp/PoolingDataSource.java? Формат = ок
Поэтому я предполагаю, что когда вы настроили ваши DataSources как javax.sql.ConnectionPoolDataSource, вы также использовали некоторую настраиваемую фабрику (это всего лишь предположение, но я полагаю, что в противном случае у вас будут исключения приведения классов в Tomcat, поскольку их объединение в действительности не обеспечивает экземпляры javax.sql.ConnectionPoolDataSource, только javax.sql.DataSource).
Таким образом, чтобы ответить на вопросы о преимуществах или недостатках конкретного случая, вы должны сравнить Apache DBCP с механизмом объединения в вашей фабрике DataSource, какой бы вы ни использовали.
Что касается документации по Java, она содержит следующее:
Интерфейс DataSource реализован поставщиком драйверов. Существует три типа реализаций:
Базовая реализация - создает стандартный объект Connection
Реализация пула соединений - создает объект Connection, который автоматически участвует в пуле соединений. Эта реализация работает с менеджером пула соединений среднего уровня.
Реализация распределенной транзакции - создает объект Connection, который может использоваться для распределенных транзакций и почти всегда участвует в пуле соединений. Эта реализация работает с менеджером транзакций среднего уровня и почти всегда с менеджером пула соединений.
API-интерфейс PooledConnection Java 7
Программист приложений не использует интерфейс PooledConnection напрямую; скорее он используется инфраструктурой среднего уровня, которая управляет пулами соединений.
Когда приложение вызывает метод DataSource.getConnection, оно возвращает объект Connection. Если выполняется пул соединений, этот объект Connection фактически является дескриптором объекта PooledConnection , который является физическим соединением.
Менеджер пула соединений , обычно сервер приложений, поддерживает пул объектов PooledConnection ....
Итак, в конце вы просто используете DataSource и Connection классы и никогда PooledConnection / ConnectionPoolDataSource , если вы счастливый и нормальный программист.
Если вы реализуете сервер приложений, это другая история ...