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

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

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

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

Ответ 1

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

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

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

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

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

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

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

Ответ 2

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

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

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

Ответ 3

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

API DataSource Java 7

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

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

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

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

API-интерфейс PooledConnection Java 7

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

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

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

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

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